Why tuples are not ranges?

[Mr.Bingo]

On Thursday, 28 June 2018 at 16:02:59 UTC, Alex wrote:
> On Thursday, 28 June 2018 at 14:35:33 UTC, Mr.Bingo wrote:
>> Seems like it would unify things quite a bit.
>
> Yeah... this is, because you can't popFront on a tuple, as the 
> amount of entries is fixed. You can, however, popFront on every 
> range.
>
> But as Timoses wrote you can easily make a range out of a 
> tuple, for example by slicing:
>
> ´´´
> import std.typecons, std.range, std.array, std.algorithm, 
> std.stdio;
>
>     void main()
>     {
>         auto t = tuple(3,4,5,6);
> 		auto m = [t[]];
>         writeln(m.map!(a => 3*a).sum());
>     }
> ´´´

But is this going to be optimized?

BTW, surely the tuple has a popFront! Just pop the last element 
and returns a new tuple.

That is, a tuple is a range! Just because it doesn't implement 
the proper functions doesn't mean it can't do so.

It is clearly easy to see if a tuple is empty, to get the front, 
and to pop the front and return a new tuple with n - 1 elements, 
which is really just the tuple(a sliced tuple, say) with the 
first member hidden.

Since a tuple is fixed at compile time you can "virtually" pop 
the elements, it doesn't mean that a tuple is not a range.

So, maybe for it to work the compiler needs to be able to slice 
tuples efficiently(not convert to dynamic arrays).

This is moot if the compiler can realize that it can do most of 
the work at compile time but I'm not so sure it can.

I mean, if you think about it, the memory layout of a tuple is 
sequential types:

T1
T2
...

So, to popFront a tuple is just changing the starting offset.