Hacker News new | past | comments | ask | show | jobs | submit login

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.



Anonymous 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).


It'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.


Nice 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.


> 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.


Out 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: