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

[Saurabh Das via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote:
> On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
>> I understand that. We just have a different perspective on the 
>> problem. Your priorities:
>>
>> - don't break what's not broken
>> - .slice! lends on opSlice and should return by ref
>>
>> My priorities:
>>
>> - type of .slice! should be as if constructing with same
>>   values from scratch
>> - keep code additions in Phobos to a minimum
>>
>> Why do I insist on the return type? Because surprisingly 
>> simple code breaks if it doesn't match. Not everything can be 
>> covered by runtime conversions in D.
>
> I think the key question is, do users care about being able to 
> modify the original `Tuple` instance indirectly through `slice`?
>
> If yes, then the only workable solutions I can see are:
>
> 1) My current proposal (insert a hidden padding member at the 
> beginning of the slice `Tuple`)
>
> 2) Don't return a `Tuple` at all - return a dedicated 
> `TupleSlice` type that is implicitly convertible to `Tuple`. 
> This approach would work with the example you came up with, but 
> implementing `TupleSlice` well could be very complex, I think.
>
> If not, then I have no fundamental objection to Saurabh Das' 
> approach, although I think the PR needs work.

The PR definitely needs work - it was proposed to outline the 
direction. I haven't worked at all on Phobos and I am not yet 
knowledgeable on writing library-quality code in D.

I'm hoping to contribute back to Phobos this year - so pointing 
out as many flaws will help learn faster :) In particular - the 
inout problem in the PR - I'm not sure yet on how to fix that.

Thanks,
Saurabh

>
> We should start a new thread in "General" to ask whether people 
> care about the `ref`-ness of `Tuple` slices is really the 
> deciding factor.