On Tue, Aug 18, 2020 at 7:38 AM Frederik Zipp <[email protected]> wrote:
>
> The draft syntax for type lists is a comma separated list:
>
> type SignedInteger interface {
> type int, int8, int16, int32, int64
> }
>
> Wouldn't it be more consistent with existing Go syntax regarding types if it
> was a semicolon separated list in curly braces?
>
> type SignedInteger interface {
> type {int; int8; int16; int32; int64}
> }
Adding to what others have said, I don't see why this syntax is more
consistent with existing syntax. Both struct fields and interface
methods, which are separated using semicolons, are an example of
concatenation: the fields and methods are concatenated together, and
all the concatenated elements are present in the final type. Type
lists as used in constraints are an example of alternation: exactly
one of the types is chosen. I can't think of any other example of
alternation in Go, so there isn't any syntax to be consistent with.
> If some day, somehow, type lists should emerge from 'interface' as
> non-nilable sum types, the natural syntax would be:
>
> type MySum type {
> A
> B
> }
>
> var mySum type{A; B}
>
> Even if this will never happen, this thought experiment suggests that curly
> braces and semicolons are the more Go-like syntax choice for type lists.
If we were to introduce non-nilable sum types, I think it would be
quite unlikely that the syntax would be "type MySum type { ... }".
That seems fairly obscure. Admittedly, that might be a reason to use
a different syntax in type constraints. But it's not a convincing
argument for using "type { A; B }" in a type constraint.
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/CAOyqgcUg2oHhLy9YL1xxC0PDZyw9awBwhe_Hzb2_F%2BQj2gZ6WQ%40mail.gmail.com.
