I look at what Carla did write and it feels ... good. I don't know, it may be not for everyone, but for me [T any] looks cleaner than [type T]. Probably I see `[` and understand this is generic params, then `T` and I immediately understand this is how the generic type denoted. A final touch, I would seriously consider this idea.
суббота, 25 июля 2020 г. в 23:22:24 UTC+3, Ian Lance Taylor: > On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts > <[email protected]> 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 [email protected]. > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1075c5dd-d876-46db-8385-d2fae9c53366n%40googlegroups.com.
