[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #54 from monarchdodra at gmail.com 2013-03-27 10:43:35 PDT ---
I think I agree that implementing it in the language is a better choice. For
one, it means $ will *always* work, as opposed to having to import std.range
just to expect generic code to work. As long as it's properly documented, I
don't really view the length => $ conversion problematic. Yes, it allows
illegal code to compile, but doesn't break anything existing (except for
strange static ifs?), and we would be giving users a way to prevent it.

I don't view that it wouldn't work "out of the box" with infinite ranges as
problematic. There is really no way around the fact that for an infinite range
to support "slice to end", it must implement it via a "DollarToken" approach,
which pretty much means the code *has* to be deployed. So there is no way to
"accidently" forget opDollar.

--------

That said, if we do go ahead and implement this, I STRONGLY urge we enforce
"hasSlicing" => "can slice to end", even for infinite ranges. Having used
infinite ranges in phobos, I can say that:
1. A *LOT* of the slicing that occurs is very often of the form r[i .. $].
2. A *LOT* of algorithms in phobos would naturally support sliceable infinite
ranges with no extra code, if they could rely on being able to write r[i .. $].

Being able *reliably* slice *finite* ranges with opDollar is only half of what
we need.

I don't think this would break a lot of code as:
1. We are modifying a *trait*, so code that slices would not actually be broken
2. Most of *our* algorithms have fall-backs should a range seize to be
sliceable.
3. There are very little infinite ranges anyways

@jmdavis: Would you be willing to go forward with such a change? You said "I'm
very much inclined to put a note in the changelog (probably in red) [...]"
would you be inclined to do such a note for only infinite ranges?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------