On Sunday, 7 February 2016 at 02:51:49 UTC, tsbockman wrote:
On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote:
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.
I think the key question is, do users care about being able to
modify the original `Tuple` instance indirectly through `slice`?
If yes, then the only workable solutions I can see are:
1) My current proposal (insert a hidden padding member at the
beginning of the slice `Tuple`)
2) Don't return a `Tuple` at all - return a dedicated
`TupleSlice` type that is implicitly convertible to `Tuple`.
This approach would work with the example you came up with, but
implementing `TupleSlice` well could be very complex, I think.
If not, then I have no fundamental objection to Saurabh Das'
approach, although I think the PR needs work.
The PR definitely needs work - it was proposed to outline the
direction. I haven't worked at all on Phobos and I am not yet
knowledgeable on writing library-quality code in D.
I'm hoping to contribute back to Phobos this year - so pointing
out as many flaws will help learn faster :) In particular - the
inout problem in the PR - I'm not sure yet on how to fix that.
Thanks,
Saurabh
We should start a new thread in "General" to ask whether people
care about the `ref`-ness of `Tuple` slices is really the
deciding factor.
