[Issue 7177] $ should forward to length by default

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Mar 24 17:52:44 PDT 2013


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



--- Comment #50 from Kenji Hara <k.hara.pg at gmail.com> 2013-03-24 17:52:41 PDT ---
(In reply to comment #47)
> @Kenji, shall we go for this?

I always think that is not good to enforce particular semantics to the user
programs. This enhancement violates the rule, and we already have an example
that we should not do it (AA and containers like that).

(I know we already have special treatement for ranges - foreach can recognize
the object with input range primitives is iterable. But this enhancement just
only works for random access range. It is too specialized.)

And I found that this is not sufficient - it does not work for
infinite forward range!

https://github.com/9rnsr/phobos/commit/dd0d4c139828013c34e76acc74884341f31db298#L0R1379

    struct IFR  // infinite forward range
    {
        enum empty = false;
        @property front() { return 1; }
        auto popFront() {}

        @property save() { return this; }

        auto opSlice(size_t b, size_t e) { return this.take(e - b); }
        auto opSlice(size_t b, Infinity) { return this; }
    }

IFR does not have 'length' primitive, but should be slicable like r[n .. $];
(see std.range.hasSlicing definition) But this enhancement cannot cover this
- therefore user defined IFR should always define their own opDollar.

So, I think the combination of std.range.opDollar and UFCS would be much better
than compiler's implicit alias just only for 'length' primitive.

-- 
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