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
