Great catch! I would say I really like it! суббота, 25 июля 2020 г. в 23:37:39 UTC+3, Carla Pfaff:
> 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/cecba51d-1718-44e0-b088-3d6b5f194c09n%40googlegroups.com.
