Just to clarify, the intent is to make the declaration in the spec `type
any = interface{}`, not `type any interface{}`, correct? The latter would
be more analogous to `error`. Either has certain advantages and
disadvantages, I'm not sure which I prefer, but I just want to make sure I
understand the plan :)
> But in my opinion that would, so far, not pass a code review within the
Go project per se. (It would definitely not pass my code review.)
It wouldn't pass my review either - but the only reason for that is that it
trades off the overhead of looking up the definition of `any` for the
convenience of typing/reading `interface{}`. With a predeclared identifier
that's part of the language, the downsides of this tradeoff vanish.
> Use of "any" makes it look like f returns an *int and f() is nil, but it
is not, because "any" is interface{}.
Apart from what others have said in general, the elephant in the room is,
of course, `error`. I don't think pre-declaring a name for an interface
changes the equation here.
On Fri, Aug 21, 2020 at 8:22 AM Bakul Shah <ba...@iitbombay.org> wrote:
> On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor <i...@golang.org> wrote:
> >
> > After many discussions and reading many comments, we plan to move
> > forward with some changes and clarifications to the generics design
> > draft.
> >
> > 1.
> >
> > We’re going to settle on square brackets for the generics syntax.
> > We’re going to drop the “type” keyword before type parameters, as
> > using square brackets is sufficient to distinguish the type parameter
> > list from the ordinary parameter list. To avoid the ambiguity with
> > array declarations, we will require that all type parameters provide a
> > constraint. This has the advantage of giving type parameter lists the
> > exact same syntax as ordinary parameter lists (other than using square
> > brackets). To simplify the common case of a type parameter that has
> > no constraints, we will introduce a new predeclared identifier “any”
> > as an alias for “interface{}”.
>
> Great!
>
>
> > 2.
> >
> > We’re going to simplify the rule for type list satisfaction. The type
> > argument will satisfy the constraint if the type argument is identical
> > to any type in the type list, or if the underlying type of the type
> > argument is identical to any type in the type list. What we are
> > removing here is any use of the underlying types of the types in the
> > type list. This tweaked rule means that the type list can decide
> > whether to accept an exact defined type, other than a predeclared
> > type, or whether to accept any type with a matching underlying type.
> >
> > This is a subtle change that we don’t expect to affect any existing
> > experimental code.
> >
> > We think that this definition might work if we permit interface types
> > with type lists to be used outside of type constraints. Such
> > interfaces would effectively act like sum types. That is not part of
> > this design draft, but it’s an obvious thing to consider for the
> > future.
> >
> > Note that a type list can mention type parameters (that is, other type
> > parameters in the same type parameter list). These will be checked by
> > first replacing the type parameter(s) with the corresponding type
> > argument(s), and then using the rule described above.
>
> Still uncomfortable with this. Will try to expand on this in a separate
> email.
>
> > 3.
> >
> > We’re going to clarify that when considering the operations permitted
> > for a value whose type is a type parameter, we will ignore the methods
> > of any types in the type list. The general rule is that the generic
> > function can use any operation permitted by every type in the type
> > list. However, this will only apply to operators and predeclared
> > functions (such as "len" and "cap"). It won’t apply to methods, for
> > the case where the type list includes a list of types that all define
> > some method. Any methods must be listed separately in the interface
> > type, not inherited from the type list.
> >
> > This rule seems generally clear, and avoids some complex reasoning
> > involving type lists that include structs with embedded type
> > parameters.
>
> You seem to be saying a generic function can use operator X only if
> if *every* type in the type list implements it. Thus if I have
>
> type foo interface { int; someSLice }
>
> I can't use + and I can't use len(), right?
>
> --
> 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/10264F88-82EB-4E01-AF28-E2057C08571E%40iitbombay.org
> .
>
--
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/CAEkBMfFr20NuDTe3pA8J9bZDObQK5nbJrNRjk-Zcb9W4r5Ot9g%40mail.gmail.com.
