Is this a bug in std.typecons.Tuple.slice?

[Marc Schütz via Digitalmars-d-learn]

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.