Am Sat, 06 Feb 2016 07:57:08 +0000 schrieb tsbockman <thomas.bock...@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