[generics] use of new predeclared name `any`

[LeoY]

Hi,

Following the blog post about generics in Go, I want to join Ian about his claim to "Minimize new concepts".

Would it be possible to allow a syntax that just omits a type constraint in the generic function definition instead of using  any ? Then the following syntax will be valid:

func F[T1, T2 Constraint](p1 T1, p2 T2) { ... }  

And will define a function F with two generics T1 and T2 where T1 has no constraints and T2 has a constraint described by the Constraint interface.

If it complicates the syntax, would it be possible to reuse blank identifier syntax. The same function will look like:

func F[T1 _, T2 Constraint](p1 T1, p2 T2) { ... }    

The goal is just to avoid introducing another predeclared name. Basically, any is a predefined declaration of the empty interface:

type any interface { }

I think adding it contradicts the main goals of Golang. Will be happy to hear your opinion about it.

Thank you,
        minherz
---------------------------------------------------------
I declare that I operate by "Crocker's Rules"

[Ian Lance Taylor]

On Wed, Dec 23, 2020 at 9:03 AM LeoY <min...@gmail.com> wrote:
>
> Following the blog post about generics in Go, I want to join Ian about his claim to "Minimize new concepts".
> Would it be possible to allow a syntax that just omits a type constraint in the generic function definition instead of using any ? Then the following syntax will be valid:
> func F[T1, T2 Constraint](p1 T1, p2 T2) { ... }

This syntax is valid in the current design draft. It means that T1
and T2 are two different type parameters, but both are constrained by
Constraint. That is, type parameter lists act like ordinary type
parameter list with respect to how names are associated with
types/constraints.

> And will define a function F with two generics T1 and T2 where T1 has no constraints and T2 has a constraint described by the Constraint interface.
> If it complicates the syntax, would it be possible to reuse blank identifier syntax. The same function will look like:
> func F[T1 _, T2 Constraint](p1 T1, p2 T2) { ... }
>
> The goal is just to avoid introducing another predeclared name. Basically, any is a predefined declaration of the empty interface:
> type any interface { }
>
> I think adding it contradicts the main goals of Golang. Will be happy to hear your opinion about it.

The suggestion here is to use a constraint of "_" as meaning "any" aka
"interface{}". I don't think we ever considered that.

I'm not sure I like it; currently "_" means an unused or discarded
value, and that isn't the meaning here. I'm not sure people less
familiar with Go will understand the special meaning in this case.
And ordinary parameter lists do not permit specifying a type of "_".
But that's just a personal preference. As far as I can tell, it would
work.

Ian

[Matt Harden]

Although "any" is a new predefined identifier, I still find that conceptually simpler than assigning a second meaning to "_".

--
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/CAOyqgcUqk7yJ2%2Br7dvyfOybh4B08FBp%2BCHLUvO1NGHdvW-JbEg%40mail.gmail.com.

[LeoY]

Thank you, Ian. Is there any desire to avoid introducing a new predefined name? Is it going to be just an empty interface definition in one of the core language modules similar to the following:

type any interface { }

If this is a case would be syntactically similar to have a function declaration that uses empty interface explicitly:

func F[T interface{}] (p T) { ... } 

Thank you,
        Leo

---------------------------------------------------------
I declare that I operate by "Crocker's Rules"

[Ian Lance Taylor]

On Thu, Dec 24, 2020 at 4:04 AM LeoY <min...@gmail.com> wrote:
>
> Thank you, Ian. Is there any desire to avoid introducing a new predefined name? Is it going to be just an empty interface definition in one of the core language modules similar to the following:
>
> type any interface { }
>
> If this is a case would be syntactically similar to have a function declaration that uses empty interface explicitly:
>
> func F[T interface{}] (p T) { ... }

Yes, the predeclared name "any" is an alias for "interface{}". In the
current design draft the name "any" is only recognized as a type
parameter constraint. It's not recognized in general. If the
generics proposal is adopted, then it would be worth considering
making "any" an ordinary predeclared type alias, similar to "byte" and
"rune". But that will be a discussion separate from generics in
general.

In practice we believe it will be common to have type parameters
without constraints. In particular that is how generic containers
will work. Always writing [T interface{}] did not seem ideal, so we
introduced "any" to permit writing [T any]. Adding a new predeclared
name is definitely a cost (the generics design draft also introduces
"comparable"). In this case it seems to us that the benefit is worth
the cost.

Ian