[generics] type list suggestion
167 views
Skip to first unread message
jimmy frasche
Jun 20, 2020, 6:51:41 PM6/20/20
to golang-nuts
I really like how the latest generics draft has progressed, fantastic
work. The only thing that doesn't really feel perfect yet is type
lists.
I like the idea of all constraints being interfaces and I get why
interfaces with type lists and/or comparable are only constraints for
now. I'd rather they be valid interfaces. For comparable that has a
natural definition [1], but for type lists it's less obvious.
[1] https://github.com/golang/go/issues/27481
If an interface with a type list is used as a sum type, it generally
would want to restrict on exact type identity, just like a constraint
generally does not want exact type identity. It would be strange if
how the type list matched changed based on context.
What if type lists could specify for each type whether it wants exact
identity or the kind used in the draft?
Since this is similar to the difference between
type A B
and
type A = B
I'll use
type =X, Y
to mean X is matched using the rules in the draft but Y must exactly
match, so every example in the draft would need to be prefixed.
Type assertions and switches could use this notation:
type Str string
var i interface{} = Str("x")
s, ok := i.(=string) // ok is true, s is type string
switch v.(type) {
case =float32, =float64:
case string:
case =string:
}
(probably the = variety would only be for interfaces with type lists
or perhaps only in generic code).
It would be rare to want to use exact matches in interfaces as
constraints and rare to use underlying matches in interfaces as
values, but this would let both cases be handled uniformly yet
distinctly.
work. The only thing that doesn't really feel perfect yet is type
lists.
I like the idea of all constraints being interfaces and I get why
interfaces with type lists and/or comparable are only constraints for
now. I'd rather they be valid interfaces. For comparable that has a
natural definition [1], but for type lists it's less obvious.
[1] https://github.com/golang/go/issues/27481
If an interface with a type list is used as a sum type, it generally
would want to restrict on exact type identity, just like a constraint
generally does not want exact type identity. It would be strange if
how the type list matched changed based on context.
What if type lists could specify for each type whether it wants exact
identity or the kind used in the draft?
Since this is similar to the difference between
type A B
and
type A = B
I'll use
type =X, Y
to mean X is matched using the rules in the draft but Y must exactly
match, so every example in the draft would need to be prefixed.
Type assertions and switches could use this notation:
type Str string
var i interface{} = Str("x")
s, ok := i.(=string) // ok is true, s is type string
switch v.(type) {
case =float32, =float64:
case string:
case =string:
}
(probably the = variety would only be for interfaces with type lists
or perhaps only in generic code).
It would be rare to want to use exact matches in interfaces as
constraints and rare to use underlying matches in interfaces as
values, but this would let both cases be handled uniformly yet
distinctly.
Ian Lance Taylor
Jun 22, 2020, 5:40:52 PM6/22/20
to jimmy frasche, golang-nuts
jimmy frasche
Jun 22, 2020, 6:03:55 PM6/22/20
to Ian Lance Taylor, golang-nuts
Fair enough that I'd missed the last sentence.
However, if you mark the types that require exact matches you can't
reuse the same sigil in type assertion/switches, so it's unclear how
those would work.
Plus, it just seems backwards since exact is the default everywhere else.
However, if you mark the types that require exact matches you can't
reuse the same sigil in type assertion/switches, so it's unclear how
those would work.
Plus, it just seems backwards since exact is the default everywhere else.
Ian Lance Taylor
Jun 22, 2020, 6:45:40 PM6/22/20
to jimmy frasche, golang-nuts
On Mon, Jun 22, 2020 at 3:03 PM jimmy frasche <soapbo...@gmail.com> wrote:
>
> Fair enough that I'd missed the last sentence.
>
> However, if you mark the types that require exact matches you can't
> reuse the same sigil in type assertion/switches, so it's unclear how
> those would work.
>
> Plus, it just seems backwards since exact is the default everywhere else.
Yes, it's imperfect. We spent a few weeks looking for a good solution
>
> Fair enough that I'd missed the last sentence.
>
> However, if you mark the types that require exact matches you can't
> reuse the same sigil in type assertion/switches, so it's unclear how
> those would work.
>
> Plus, it just seems backwards since exact is the default everywhere else.
here but couldn't find one, so we decided to push forward. We don't
want to optimize for sum types, since we're not at all sure that
interfaces with type lists are suitable for use as sum types. Most
people who want sum types don't want the zero value to be nil.
Ian
jimmy frasche
Jun 22, 2020, 7:38:58 PM6/22/20
to Ian Lance Taylor, golang-nuts
> Most people who want sum types don't want the zero value to be nil.
I am certainly one of those people, but, if interfaces with type lists
can be used for sum types and generics constraints, it's well worth
the trade off for keeping the language simple.
My major concern with the current notation is that it may make it too
awkward to change later so type lists would be stuck as
constraint-only. Even if better sum types that I'd be happier with are
added later there would be overlap and footnotes.
Reply all
Reply to author
Forward
0 new messages