Is this a bug in std.typecons.Tuple.slice?
Marco Leise via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sat Feb 6 18:11:15 PST 2016
Am Sat, 06 Feb 2016 07:57:08 +0000
schrieb tsbockman <thomas.bockman at gmail.com>:
> On Saturday, 6 February 2016 at 06:34:05 UTC, Marco Leise wrote:
> > I don't want to sound dismissive, but when that thought came
> > to my mind I considered it unacceptable that the type of
> > Tuple!(int, bool, string).slice(1, 3) would be something
> > different than Tuple!(bool, string). In your case
> > Tuple!(TuplePad!4LU, bool, string). That's just a matter of
> > least surprise when comparing the types.
> >
> > I'll let others decide, since I never used tuple slices.
>
> I'm not sure which approach is ultimately better, but aside from
> the performance implications, your "needed change" could break a
> lot of valid code in the wild - or it might break none; it really
> just depends on whether anyone actually *uses* the `ref`-ness of
> the `Tuple.slice` return type.
True.
> (It appears that Phobos, at least, does not. But there is no
> guarantee that the rest of the world is using `Tuple` only in the
> ways that Phobos does.)
> Leaving aside bizarre meta-programming stuff (because then
> *anything* is a breaking change), my PR does not break any code,
> except that which was already broken: the type of the slice is
> only different in those cases where it *has* to be, for alignment
> reasons; otherwise it remains the same as it was before.
I understand that. We just have a different perspective on the
problem. Your priorities:
- don't break what's not broken
- .slice! lends on opSlice and should return by ref
My priorities:
- type of .slice! should be as if constructing with same
values from scratch
- keep code additions in Phobos to a minimum
Why do I insist on the return type? Because surprisingly
simple code breaks if it doesn't match. Not everything can be
covered by runtime conversions in D. It still took me a while
to come up with something obvious:
uint[Tuple!(uint, ulong)] hash;
auto tup = tuple(1u, 2u, 3UL);
hash[tup.slice!(1, 3)] = tup[0];
compiles? works?
original Tuple : yes no
Saurabh Das changes: yes yes
your changes : no no
What I like most about your proposal is that it doesn't break
any existing code that wasn't broken before. That can't be
emphasized enough.
--
Marco
More information about the Digitalmars-d-learn
mailing list