> But I don't think that using type list constraint as sum types is good
idea.
> Type constraints should be known in compile-time, but the sum type
variant should be known in run-time.
It looks like you misunderstand it a bit. Indeed
type Constraint interface {
type Type₁, Type₂, …, Typeₙ
}
was introduced as a meta-construct. Some people, including me, were not
particularly happy about it, as it
cannot be used as a value type and assymetry appears: all interfaces can be
used as a constraint yet there
are interfaces that can't. An obvious inconsistency. So, they (the Go team)
addressed this with an idea to
utilize such kind of interfaces for runtime values as a sum type.
I really wish they make it into Go together with generics too. Some parts
of my code would finally be
straightforward.
пятница, 4 сентября 2020 г. в 21:45:48 UTC+3, tdakkota:
> I'd like to see sum types in Go2 and there are many reasons:
> - It can make using oneOf/anyOf in protobuf or swagger mush easier.
> - It can make ast.Node type-safe.
> - With sum-types compiler known maximum size of variant, so it can be
> allocated on stack, not on heap.
>
> But I don't think that using type list constraint as sum types is good
> idea.
> Type constraints should be known in compile-time, but the sum type variant
> should be known in run-time.
> пятница, 21 августа 2020 г. в 03:28:23 UTC+3, Ian Lance Taylor:
>
>> 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{}”.
>>
>> The result is declarations that look like this:
>>
>> type Vector[T any] []T
>> func Print[T any](s []T) { … }
>> func Index[T comparable](s []T, e T) { … }
>>
>> We feel that the cost of the new predeclared identifier “any” is
>> outweighed by the simplification achieved by making all parameter
>>
> lists syntactically the same: as each regular parameter always has a
>> type, each type parameter always has a constraint (its meta-type).
>>
>> Changing “[type T]” to “[T any]” seems about equally readable and
>> saves one character. We’ll be able to streamline a lot of existing
>> code in the standard library and elsewhere by replacing “interface{}”
>> with “any”.
>>
>> 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.
>>
>> 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.
>>
>> 4.
>>
>> We’re going to permit type switches on type parameters that have type
>> lists, without the “.(type)” syntax. The “(.type)” syntax exists to
>> clarify code like “switch v := x.(type)”. A type switch on a type
>> parameter won’t be able to use the “:=” syntax anyhow, so there is no
>> reason to require “.(type)”. In a type switch on a type parameter
>> with a type list, every case listed must be a type that appears in the
>> type list (“default” is also permitted, of course). A case will be
>> chosen if it is the type matched by the type argument, although as
>> discussed above it may not be the exact type argument: it may be the
>> underlying type of the type argument. To make that rule very clear,
>> type switches will not be permitted for type parameters that do not
>> have type lists. It is already possible to switch on a value “x”
>> whose type is a type parameter without a type list by writing code
>> like “switch (interface{})(x).(type)” (which may now be written as
>> “switch any(x).(type)”). That construct is not the simplest, but it
>> uses only features already present in the language, and we don’t
>> expect it to be widely needed.
>>
>>
>> These changes will soon be implemented in the experimental design on
>> the dev.generics branch, and in the go2go playground. Some of them
>> already work. We will update the design draft accordingly.
>>
>>
>> We welcome any comments. Thanks for all the help that so many people
>> have provided so far.
>>
>> Ian & Robert
>>
>
--
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/ab2c3fc2-72d3-4933-b51c-5cf616d90d78n%40googlegroups.com.
