On Monday, 29 October 2012 at 15:48:47 UTC, Andrei Alexandrescu
wrote:
On 10/29/12 11:43 AM, monarch_dodra wrote:
I think you missed the point
... which I think Dmitry destroyed.
Andrei
The only point he contested was the optimization opportunities in
std.algorithm.
I agree that optimization opportunities are not enough to warrant
new concepts, but that wasn't my main point. But they are there
is what I was saying.
(PS: There is currently a pull request for making copy exploit
doubly RA ranges)
--------
My main point is that slicing a range to its end *is* something
important, and we currently have nothing to provide this
functionality, when we could (easily).
The argument: "I'm thinking that simply defining an opDollar to
return
special marker type and overloading opSlice should work", works,
but brings its own issues to the table.
Inside template code, it would render hasSlicing *even more*
complex: If an infinite range indeed has slicing, then what
exactly does it mean?
- Does it mean you can slice between two indexes?
- Does it guarantee you can slice to the end with opDollar?
- Does it mean you can do both?
- Would it imply that "r[0 .. 1]" would have a different type
from "r[0 .. $]" ?;
- Would it imply that "r = r[0 .. $]" is legal?
- What about that "r = r[0 .. 10]"?
And still, that'd be if anybody actually used opDollar... *cough*
--------
The solution I'm proposing barely requires anything new we don't
already have (popFrontN).
I'm saying we can exploit the existence of this method to clearly
separate the two (currently conflicting) notions of slicing we
currently have:
*On one hand, we can have the "hasSlicing" ranges, where can
clearly write "r = r[0 .. 10];" any day of the week, no matter
the range.
*On the other end, we'd have "isDroppable", which would give you
two limited features for those ranges that don't satisfy
hasSlicing:
**Slice to end with guaranteed assignability to original "r =
r.drop(10);"
**Extract a slice, but with the explicit notion you *won't* get
back-assignability "auto myNewSlice = r.extractSlice(0, 10);"
Note that this "extractSlice" notion would save a bit of
functionality for immutable ranges which *would* have slicing,
but since they don't support assign, don't actually verify
hasSlicing...
