I know it's common to have no constraints, but "[Elem any]" is even one
character shorter than "[type Elem]". I rewrote the function signatures
from slices.go2 in this way, and it doesn't feel painful. This already
works on the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr
On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:
> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts
> <golan...@googlegroups.com> wrote:
> >
> > To expand on my post:
> > It would be very consistent with the structure of regular parameter
> lists. Just like every parameter in a regular parameter list must have a
> type (with the exception of multiple consecutive parameters having the same
> type), every type parameter in a type parameter list must have a constraint.
>
> That is certainly true.
>
> But it is also true, based on experiments writing generic code, that
> the majority of type parameters have no constraints. That is
> particularly true for type parameters of generic types. So while it
> would be possible to require people to always explicitly write a
> constraint, it seems painful to force people to always write something
> that is almost never needed.
>
> Note that in this way constraints on type parameters are different
> from types of regular parameters. It makes no sense to speak of a
> regular parameter with no type. It's entirely reasonable, even
> common, to speak of a type parameter with no constraint.
>
> Ian
>
>
> > On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote:
> >>
> >> I just discovered the experiment to make the "type" keyword optional in
> certain cases on the dev.go2go branch. The commit message says:
> >>
> >> ---
> >> Experiment: Make "type" keyword optional in generic type declarations
> when
> >> it is clear that we can't have an array type declaration. This is the
> case
> >> when we have one the following:
> >>
> >> - more than one type parameter
> >> - a type parameter with a constraint
> >> - a trailing comma in the type parameter list
> >> --
> >>
> >> If the "type" keyword is not necessary if a constraint is present, then
> why not make a constraint mandatory and get rid of the "type" keyword in
> type parameter lists altogether?
> >>
> >> Before:
> >>
> >> func Filter[type Elem](...)
> >> func Map[Elem1, Elem2](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> >> After:
> >>
> >> func Filter[Elem interface{}](...)
> >> func Map[Elem1, Elem2 interface{}](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> >> "interface{}" may be a little bulky, especially it since it is usually
> used for the simple cases. But if there was a short type alias for
> "interface{}" like "any" it can look good:
> >>
> >> type any = interface{}
> >>
> >> func Filter[Elem any](...)
> >> func Map[Elem1, Elem2 any](...)
> >> func Max[Elem constraints.Ordered](...)
> >>
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%40googlegroups.com
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/751b84b1-c3b6-4b81-8b9d-845805dc1ae5n%40googlegroups.com.
