"isDroppable" range trait for slicing to end

[monarch_dodra]

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...