[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

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



--- Comment #69 from monarchdodra at gmail.com 2013-04-02 08:13:42 PDT ---
(In reply to comment #67)
> (In reply to comment #66)
> > 
> > https://github.com/9rnsr/phobos/commit/dd0d4c139828013c34e76acc74884341f31db298#L0R1326
> 
> I think this is a good compromise. Unless there are other issues found by
> others, I agree moving forward with this. More thoughts?

So to wrap things up, both for myself or those who have lost track:

What we are finally doing is allowing opDollar (and only opDollar) to be
implemented UFCS style, correct?

Then, inside std.range, we provide a "global range" opDollar function. This
will mean that ranges (and only ranges) will  have $ => length? Is this correct
so far? And in the special case of infinite ranges, it will convert to an empty
object (Infinity)?

Sounds good to me. We'll just have to keep in mind that:
a) $ will be automatically provided *only* if the user imports std.range
(failure to import it will mean failure to use opDollar)
b) Implementations may still want to explicitly provide the alias, for "native"
opDollar: std.range.opDollar will only be "fall back" implementation.
To be frank, I'm 100% fine with that.

Other than that: Nitpick time!
1) The "Infinity" struct name is pretty vague. J.M. Davis and I have been using
the term "DollarToken" so far. Any chance we use that instead? It has the
advantage of being bound to the word "dollar". It can also be used for
non-infinite ranges that still want to exploit end slicing.
2) I think providing opDollar for InputRanges (as opposed to ForwardRange) is
better. I don't see why we'd want to go out of our way to cripple InputRanges.

That's it.

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