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.