"isDroppable" range trait for slicing to end

[Dmitry Olshansky]

10/31/2012 4:48 AM, Jonathan M Davis пишет:
> On Monday, October 29, 2012 15:33:00 monarch_dodra wrote:
>> More often than not, we want to slice a range all the way to the
>> end, and we have to use the clumsy "r[0 .. r.length]" syntax.
>>
>> What's worst is that when a range is infinite, there is no real
>> way to "slice to the end", unless you just repeatedly popFront.
>
> As already pointed out, this is solved by opDollar. We don't have a trait for
> it, but it can be tested for easily enough by doing something like
> typeof(is(r[0 .. $])) or __traits(compiles, r[0 .. $]). We may still want to
> create a trait for it though (e.g. hasOpDollar).
>

I just wanted to point out that we may as well require all RA ranges to 
have opDollar. Finite already have length, infinite would have marker.
Just need some migration path so that current RA won't lose their title 
over night.

[snip]
> Finite ranges which could have n elements popped in O(1) would be sliceable
> anyway, meaning that popFrontN would be O(1) for them already and that if a
> function requires popping n elements in O(1), it can just slice the range. So,
> isDroppable buys us nothing for finite ranges. The only gain that I really see
> here is that it would provide a way for infinite ranges to pop off their first n
> elements and still be infinite. As it stands, the best that you can do is slice
> them, but that has to result in another range type, because a finite slice
> can't be infinite.

Yes, the whole argument started with infinite ranges.

>
> However, if we take advantage of opDollar, then I think we can solve the
> problem that way. By using opDollar when slicing an infinite range, you should
> be able to keep the original range type. That being the case, I don't think
> that isDroppable is really necessary.

I said elsewhere I have feeling that hasSlicing should really check for
x = x[a..b];

Whereas for infinite ranges we need a weaker trait 
isDropable/hasSlicingToEnd(??):

x = [a..$];

> Howevere, it _does_ mean that I should
> probably adjust my pull for hasSlicing so that it tests that slicing an
> infinite range with opDollar returns the original type (assuming that opDollar
> compiles for it). Of course, once opDollar works (I don't know what it's
> current state is), it would be desirable to require it to work with slicing
> anyway, so maybe hasSlicing should have that requirement added at a later
> date.

Indeed, alternatively we can check for both hasSlicing and isInfinite.
Then in case of Infinite = true slicing only works up to $, this could 
be a better idea.

-- 
Dmitry Olshansky