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
<http://www.sl4.org/crocker.html>"


On Wed, 23 Dec 2020 at 19:26, Ian Lance Taylor <[email protected]> wrote:

> On Wed, Dec 23, 2020 at 9:03 AM LeoY <[email protected]> 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
>

-- 
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/CALuHfSMFK_cxPLx37kpXOKrDvwviWtXpVqKxxfopEv9V8g0Szw%40mail.gmail.com.

Reply via email to