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

[Saurabh Das via Digitalmars-d-learn]

On Saturday, 6 February 2016 at 08:01:20 UTC, tsbockman wrote:
> On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote:
>> [...]
>
> I should also point out that, since there is no way to actually 
> find out whether anyone is using the `ref`-ness of the return 
> type in the wild, the approach that you and Saurabh Das are 
> taking really ought to include changing the symbol name and 
> deprecating the old one.
>
> Otherwise you could introduce subtle bugs into previously valid 
> code; not every significant effect of removing `ref` will cause 
> an error message at compile time *or* run time - some will just 
> silently change the behaviour of the program, which is awful.

I think we should add a static assert to slice to ensure that the 
current implementation is not used in a case where the alignment 
doesn't match. This is better than failing without any warning.

We could add new (differently named) functions for slicing 
non-aligned tuples.

I agree that my approach of removing the ref may break existing 
code, so if introduced, it should be named differently.

I am not comfortable with tuple(42, true, "abc").slice(1, 3) 
being different in type from tuple(true, " abc").