Re: Does anyone care if Tuple.slice() returns by ref?
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().
Re: Does anyone care if Tuple.slice() returns by ref?
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
}
Re: Does anyone care if Tuple.slice() returns by ref?
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)));
Re: Does anyone care if Tuple.slice() returns by ref?
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.
Re: Does anyone care if Tuple.slice() returns by ref?
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.
Re: Does anyone care if Tuple.slice() returns by ref?
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?
Re: Does anyone care if Tuple.slice() returns by ref?
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.
Re: Does anyone care if Tuple.slice() returns by ref?
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.
Does anyone care if Tuple.slice() returns by ref?
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
Re: Does anyone care if Tuple.slice() returns by ref?
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.
Re: Does anyone care if Tuple.slice() returns by ref?
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?
