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.
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.
