On Tuesday, 9 February 2016 at 14:28:35 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 9 February 2016 at 13:43:16 UTC, Marc Schütz wrote:
So what? Using that argument, you could just as well forbid
taking the address of any variable. What's so special about
tuples, in contrast to structs and arrays?
Some key common qualities for a tuple:
1. They are primarily used for multiple return values from
functions.
As you said, primarily. There's no reason not to use them for
something else.
2. Tuples use structural typing, not nominal typing.
This has no relevance for the question at hand.
3. They are identity-less. If you can take reference and
compare, they no longer are identity-less.
Like value types in general, nothing special about tuples here.
Tuples should be considered immutable constants (think
functional programming), not in-memory storage.
Again, why?
Because that is how a tuple is commonly defined, for
performance and semantic reasons.
I believe it's more because the concept is more frequently used
in functional programming languages, for which immutability is
not surprising. Other languages do have mutable tuples, e.g.
Swift and C++11 (std::tuple).
Tuple's can serve as a good approximation to SIMD registers.
What relation does that have to the above?
You don't want to spill out SIMD registers to the stack if you
can avoid it. You want to do the changes within the CPU
pipeline, i.e. using copies (and register renaming).
As said above, wanting to avoid spilling is not a reason to
disallow spilling. Besides, fixed-size arrays seem more similar
to SIMD registers, and they don't have the restrictions you
tuples to have.
