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
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
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
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
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:
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.
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
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
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
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
11 matches
Mail list logo
