www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Does anyone care if Tuple.slice() returns by ref?

reply tsbockman <thomas.bockman gmail.com> writes:
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
Feb 06 2016
parent reply Saurabh Das <saurabh.das gmail.com> writes:
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?
Feb 06 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
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.
Feb 06 2016
parent reply ZombineDev <valid_email he.re> writes:
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().
Feb 07 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
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.
Feb 07 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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
}
Feb 07 2016
parent reply tsbockman <thomas.bockman gmail.com> writes:
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)));
Feb 07 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Feb 07 2016
parent reply Saurabh Das <saurabh.das gmail.com> writes:
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?
Feb 07 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Feb 07 2016
parent tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 7 February 2016 at 16:49:16 UTC, Ola Fosheim Grøstad 
wrote:

 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.


The fact that `Tuple` cannot implement `opIndex` or `opSlice`, 
but instead must use the non-standard `slice` name is a good 
indicator that the current design is less than ideal.
Feb 07 2016