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.

On Tuesday, 9 February 2016 at 16:00:09 UTC, Marc Schütz wrote:
>> 2. Tuples use structural typing, not nominal typing.
>
> This has no relevance for the question at hand.

It does if you allow casting and to use tuples a types in aggregates. The language becomes less strongly typed.

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

I don't know what you mean by that. D doesn't provide proper value types. If you can compare identities (address) then it is not a value, but an object.

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

C++ doesn't have real tuples. I don't know the details of Swift regarding tuples, but Swift is an OO language that does not aim for high performance or very strong typing.

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

Well, I disagree. There is very little reason to encourage people to use tuples for storage, you end up with a weaker typed language and less performant code.

(You can do various types of packing in registers too, depends on the CPU.)

On Tuesday, 9 February 2016 at 09:05:58 UTC, Ola Fosheim Grøstad wrote:
> I suggest lobbying for proper builtin tuple support.

Built-in tuple support would be great (although to my mind, mostly because the current syntax is clunky). But that is a long-term goal, and `Tuple.slice` is corrupting data *right now*.

Some sort of short-term fix should be merged in the next release of D.

On Wednesday, 10 February 2016 at 00:24:56 UTC, tsbockman wrote:
> [...]
> `Tuple.slice` is corrupting data *right now*.
>
> Some sort of short-term fix should be merged in the next release of D.

+1