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

[Marco Leise via Digitalmars-d-learn]

Am Sat, 06 Feb 2016 11:02:37 +0000
schrieb tsbockman <thomas.bockman at gmail.com>:

> On Saturday, 6 February 2016 at 08:47:01 UTC, Saurabh Das wrote:
> > 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.
> 
> If we pursue the deprecation route, I agree that this is a 
> necessary step.

That would hurt the least, yes. It's more like a .dup with
start and end parameter then.

> > 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").
> 
> Why? What practical problem does this cause?

For me it is mostly a gut feeling. Historically types
mimicking other types have often evoked trouble for example in
generic functions or concretely - if you look at my other post
- in D's AA implementation.

-- 
Marco