[Issue 7177] $ should forward to length by default

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Mar 21 06:18:04 PDT 2013


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


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra at gmail.com


--- Comment #11 from monarchdodra at gmail.com 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: -------


More information about the Digitalmars-d-bugs mailing list