On Tue, Aug 18, 2020 at 7:38 AM Frederik Zipp <frederik.z...@gmail.com> 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUg2oHhLy9YL1xxC0PDZyw9awBwhe_Hzb2_F%2BQj2gZ6WQ%40mail.gmail.com.