http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #69 from [email protected] 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: -------
