Thread overview | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 07, 2016 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 |
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to tsbockman | 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?
|
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Saurabh Das | 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.
|
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to tsbockman | 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(). |
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to ZombineDev | 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.
|
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to tsbockman | 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
}
|
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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)));
|
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to tsbockman | 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.
|
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | 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?
|
February 07, 2016 Re: Does anyone care if Tuple.slice() returns by ref? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Saurabh Das | 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.
|
Copyright © 1999-2021 by the D Language Foundation