On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts
<golang-nuts@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+unsubscr...@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/CAOyqgcUzEQk4eLZbVcjcpyZWw8Wp6irbhgAuaa0kw2EtWTULSg%40mail.gmail.com.
