I like it! BTW, I don't understand the meaning of this comment in the commit log:
> >> Experiment: Make "type" keyword optional in generic type declarations when > >> it is clear that we can't have an array type declaration. It is talking about defining generic arrays, where one parameter may be the number of dimensions? Probably not but IMHO such an exercise should be carried out before settling on a generic design. > On Jul 25, 2020, at 1:36 PM, 'Carla Pfaff' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > 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 > <applewebdata://688B88A9-8EBA-44E5-9D02-3A642A4CAF6F>> 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 > > <applewebdata://688B88A9-8EBA-44E5-9D02-3A642A4CAF6F>. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/golang-nuts/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%40googlegroups.com > > > > <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 > <mailto: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 > > <https://groups.google.com/d/msgid/golang-nuts/751b84b1-c3b6-4b81-8b9d-845805dc1ae5n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- 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/1FEE7F98-958D-4481-B76F-F84B3D9B9211%40iitbombay.org.
