digitalmars.D - Does anyone care if Tuple.slice() returns by ref?
- tsbockman (25/25) Feb 06 2016 I want to do a quick survey of the community, to help figure out
- Saurabh Das (3/6) Feb 06 2016 Can we keep the old by ref slice() method, but add guards to
- tsbockman (6/12) Feb 06 2016 Honestly, I think it will just confuse people if the slice-by-ref
- ZombineDev (5/18) Feb 07 2016 Contrary to my expectations, slicing bultin tuples returns a
- tsbockman (3/7) Feb 07 2016 That is surprising indeed, but I don't see how fixing it would
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (10/12) Feb 07 2016 Why won't a reinterpret cast work?
- tsbockman (8/20) Feb 07 2016 That is essentially what my PR does. But, some people are unhappy
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (4/7) Feb 07 2016 Well, Tuple is flawed by design for more than one reason. IMO it
- Saurabh Das (3/10) Feb 07 2016 Why is the design flawed?
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (4/5) Feb 07 2016 Because it breaks expectations.
- tsbockman (5/11) Feb 07 2016 The fact that `Tuple` cannot implement `opIndex` or `opSlice`,
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
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
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: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.(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
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: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 03:16:48 UTC, tsbockman wrote: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.(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 07 2016
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
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
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 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)));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
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
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:Why is the design flawed?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
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
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: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.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