-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: Go 2: add tuple type #61920
Comments
Maybe aside from syntax, this is #32941. Per #32941 (comment):
|
As noted above, a tuple type is very similar to a struct type, and so I think it's worth enumerating some of the ways that struct types are awkward to use, which a separate tuple type kind might therefore address. Here are my attempts:
I'm not intending to make any statement about how important these items are, only to start enumerating them as part of exploring whether tuple types would add enough value to be worth the additional language complexity. |
#33080 wasn't about tuple types per se but it ended up talking about them a lot |
My point 1 above could potentially be addressed with a new syntax for assigning an anonymous struct value, where the field types get chosen automatically rather than being written explicitly. I'm not sure exactly what syntax would make sense for this. Here's an initial example that I expect everyone to hate just because, as Ian often points out, it's helpful to have something horrible for everyone to agree they dislike. 😀 struct{...}{Name: "foo", Age: 6} The If the second set of braces didn't have any field names then this would essentially be a tuple type, since the compiler would need to choose some field names automatically, although automatically selecting names that are valid identifiers (rather than integers) would avoid introducing a new field access convention. Choosing names that start with letters would, in particular, force making a decision about whether they are uppercase or lowercase and thus whether the fields are exported. Since anonymous struct types don't have methods, I assume they would be exported since otherwise the fields would only be accessible in the package where the struct was written. Again I want to reinforce that I'm showing a hypothetical "anonymous struct that acts like a tuple" just as an initial hypothetical answer to how these concerns could be met without introducing a new kind of type. I don't actually like it, and invite alternatives that are less clunky but still ultimately yield something that is compatible with an anonymous struct type, and therefore hopefully a new enough take on the previous proposal (addressing the concerns raised there) to make it worth revisiting. |
Another "what if this were essentially just syntactic sugar for struct types" hypothetical: Predeclared identifiers type tuple3[T0, T1, T2 any] struct {
F0 T0
F1 T1
F2 T2
} I'm imagining these predeclared identifiers being a special case where they behave as if there are an infinite number (or perhaps The above alone would be just as cumbersome as an anonymous struct type, but with the information moved about a little and some different punctuation: tuple2[string, int]{"hello", 4} Combined with something like #61731, the explicit type parameters can vanish from the supposed-idiomatic form: tuple2{"hello", 4} At that point the only remaining redundancy is specifying the arity: the number of expressions inside the braces implies that this is
Aside from this syntactic sugar, I'd expect the resulting types/values to behave just as regular struct types. In particular, we'd access the fields using (Side-note: using parentheses for a "tuple literal" is familiar from some other languages, but I expect it's probably ambiguous in Go. It's also unlike any other composite literal; perhaps something with braces would be better.) With all of that said, I already have some reservations:
|
I came up with a similar sketch with some different tradeoffs in #33080 (comment) |
Per the discussion above, this proposal is similar to other, earlier proposals. It is also not clearly specified--what is the type of a tuple? And the emoji voting is not in favor. Therefore, this is a likely decline. Leaving open for three weeks for final comments. |
No further comments. |
Go is lack of Tuple type since first release, variadic return variables can solve this in a strange way. (At least in my thinking, what's wrong can be pointed out)
Recently a series proposals to add iterator to go, and introduce a trick type
Seq2
, this make thing even worse, we can imagine that in the near future, there may lots of trick types in std library, this should be what everyone doesn't want to see.So I propose add the long time missing type -
Tuple
to go, then theSeq2
can write toSeq[(K, V)]
, imagine()
make a list type into tuple type.Access tuple field using index number.
In function return values, we can treat it as tuple implicitly, so we can write this:
Related Iterator Proposal: #61897 and others ...
The text was updated successfully, but these errors were encountered: