7 ms·
A big advantage of this design over most of the other languages with tuples that I've seen is that their members can have names - that is, types can be anonymou
by contextfree 10y ago
A big advantage of this design over most of the other languages with tuples that I've seen is that their members can have names - that is, types can be anonymous but have named members. This I think hits a sweet spot as it's rare to not want fields to have names, but fairly common to want intermediate types that just bundle a few fields together where there's no good name that clarifies much.
- Retra 10y agoAnonymous items with named fields are always only just one name away from being structs. That seems to me to be the least-sweet spot in the possibilities of (named/anonymous item) x (named/anonymous fields).
- int_19h 10y agoIt's a very big step in a language with nominal typing. Tuples with named fields are compatible (even across assemblies, if I remember correctly) so long as order, names and types match. Structs are not compatible in that manner.
- Digit-Al 10y agoNice point. There's also the fact that with deconstruction being added as well, you don't even have to have the overhead of declaring a struct variable to get the return value and then dereferencing the fields, you can just deconstruct the tuple into variable if you so wish.
- vyrotek 10y ago> Anonymous items with named fields are always only just one name away from being structs. That's a huge line to cross though! Once you give it a name then you generally have to give it a home somewhere.
- Sanddancer 10y agoOut variables, and I imagine the various sorts of tuples, are created on the stack. Structs can by stack-allocated, or they can be heap-allocated, which has performance considerations which may be important in a given program. This feels much more like a case of right tool for the job than anything else.