http://d.puremagic.com/issues/show_bug.cgi?id=7177
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #11 from [email protected] 2013-03-21 06:18:01 PDT --- (In reply to comment #10) > https://github.com/D-Programming-Language/dmd/pull/1779 I'm a bit on the fence about this. I don't think it's the compiler's job to translate $ into length. length is not a magic word, it is just a range primitive. The compiler should have no knowledge about either of these. Further more, I think it could be dangerous to forward $ to length for any indiscriminate type. Couldn't we implement this instead as a library solution, inside std.range? For example, std.array provides (pop)[front|back] for arrays. This is library, not compiler. We could have std.range provide an global opDollar function that returns it's range argument's length instead? Simply: //-------- import std.stdio; import std.range; auto opDollar(R)(auto ref R r) if (isInputRange!R && hasLength!R) { return r.length; } struct S { @property { enum empty = false; int front(){return 1;} size_t length(){return 10;} } void popFront(){} int opIndex(size_t i){return i;} } void main() { S s; writeln(s[$]); } //-------- Idea being that if you call: R r; r[$ - 1]; Then: Either R defines opDollar, and everyone is happy. If not, and if range is imported, the the compiler "sees" an available std.range.opDollar function, and uses that instead. That doesn't work right now (it just says "undefined identifier __dollar"), so it would still require a bit of compiler improvement, but I think it would be a better direction to take. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
