I want to do a quick survey of the community, to help figure out the best way to fix Phobos issue 15645:  Tuple.slice() causes memory corruption.

https://issues.dlang.org/show_bug.cgi?id=15645

BACKGROUND: Currently, Tuple.slice() returns an actual slice: an interior pointer to some part of the original Tuple.

However, alignment issues require that the return type be something other than a standard Tuple to maintain memory safety. My PR adds a hidden padding member to the beginning of the return type: https://github.com/D-Programming-Language/phobos/pull/3973

Saurabh Das has submitted an alternative, and arguably more elegant solution (WIP): https://github.com/D-Programming-Language/phobos/pull/3975

His version simply returns the slice by value, rather than reference. This solves the memory safety issue, but it is a potentially significant breaking change.

THE QUESTION: Does anyone care? Is anyone writing code that depends upon the ref-ness of Tuple.slice()'s return type?

(If we go with Saurabh Das' approach, we'll deprecate the old slice() by ref method, so it there won't be any *silent* breakage either way.)

VOTE HERE: http://www.polljunkie.com/poll/rtjndn/fixing-ds-tupleslice-issue-15645

RESULTS (so far): http://www.polljunkie.com/poll/kpnmtk/fixing-ds-tupleslice-issue-15645/view

On Sunday, 7 February 2016 at 03:16:48 UTC, tsbockman wrote:
> (If we go with Saurabh Das' approach, we'll deprecate the old slice() by ref method, so it there won't be any *silent* breakage either way.)

Can we keep the old by ref slice() method, but add guards to disallow cases where the alignment is off?

On Sunday, 7 February 2016 at 07:00:04 UTC, Saurabh Das wrote:
> On Sunday, 7 February 2016 at 03:16:48 UTC, tsbockman wrote:
>> (If we go with Saurabh Das' approach, we'll deprecate the old slice() by ref method, so it there won't be any *silent* breakage either way.)
>
> Can we keep the old by ref slice() method, but add guards to disallow cases where the alignment is off?

Honestly, I think it will just confuse people if the slice-by-ref method only works on some seemingly-random subset of Tuple instantiations - especially since the subset that worked would be platform dependent.

We should either fix it, or deprecate it.

On Sunday, 7 February 2016 at 07:31:51 UTC, tsbockman wrote:
> On Sunday, 7 February 2016 at 07:00:04 UTC, Saurabh Das wrote:
>> On Sunday, 7 February 2016 at 03:16:48 UTC, tsbockman wrote:
>>> (If we go with Saurabh Das' approach, we'll deprecate the old slice() by ref method, so it there won't be any *silent* breakage either way.)
>>
>> Can we keep the old by ref slice() method, but add guards to disallow cases where the alignment is off?
>
> Honestly, I think it will just confuse people if the slice-by-ref method only works on some seemingly-random subset of Tuple instantiations - especially since the subset that worked would be platform dependent.
>
> We should either fix it, or deprecate it.

Contrary to my expectations, slicing bultin tuples returns a copy. (http://dpaste.dzfl.pl/fd96b17e735d)
Maybe we need to fix this in the compiler. That way we can reuse the language feature for std.typecons : Tuple.slice().

On Sunday, 7 February 2016 at 08:54:08 UTC, ZombineDev wrote:
> Contrary to my expectations, slicing bultin tuples returns a copy. (http://dpaste.dzfl.pl/fd96b17e735d)
> Maybe we need to fix this in the compiler. That way we can reuse the language feature for std.typecons : Tuple.slice().

That is surprising indeed, but I don't see how fixing it would solve the Tuple.slice() memory alignment issues.

On Sunday, 7 February 2016 at 12:28:07 UTC, tsbockman wrote:
> That is surprising indeed, but I don't see how fixing it would solve the Tuple.slice() memory alignment issues.

Why won't a reinterpret cast work?

struct tupleX {
  T0 _0;
  T1 _1;
}

struct tupleX_slice_1_2 {
  T0 _dummy0;
  T1 _0
}

On Sunday, 7 February 2016 at 12:51:07 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 7 February 2016 at 12:28:07 UTC, tsbockman wrote:
>> That is surprising indeed, but I don't see how fixing it would solve the Tuple.slice() memory alignment issues.
>
> Why won't a reinterpret cast work?
>
> struct tupleX {
>   T0 _0;
>   T1 _1;
> }
>
> struct tupleX_slice_1_2 {
>   T0 _dummy0;
>   T1 _0
> }

That is essentially what my PR does. But, some people are unhappy with the thought of a slice's type not matching the type of the equivalent standard Tuple:

Tuple!(int, bool, string) foo;
const bar = foo.slice!(1, 3)();

static assert(! is(typeof(bar) == Tuple!(bool, string)));

On Sunday, 7 February 2016 at 13:01:14 UTC, tsbockman wrote:
> That is essentially what my PR does. But, some people are unhappy with the thought of a slice's type not matching the type of the equivalent standard Tuple:

Well, Tuple is flawed by design for more than one reason. IMO it should be replaced wholesale with a clean design with consistent semantics.

On Sunday, 7 February 2016 at 13:13:21 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 7 February 2016 at 13:01:14 UTC, tsbockman wrote:
>> That is essentially what my PR does. But, some people are unhappy with the thought of a slice's type not matching the type of the equivalent standard Tuple:
>
> Well, Tuple is flawed by design for more than one reason. IMO it should be replaced wholesale with a clean design with consistent semantics.

Why is the design flawed?

On Sunday, 7 February 2016 at 16:27:32 UTC, Saurabh Das wrote:
> Why is the design flawed?

Because it breaks expectations.

Tuples should be builtin and the primarily use case is supporting multiple return values with heavy duty register optimization.