[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

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



--- Comment #55 from Andrei Alexandrescu <andrei at erdani.com> 2013-03-31 09:41:17 PDT ---
(In reply to comment #50)
> (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.)

@Kenji: I'm a bit unclear on your view on this. You mention you'd prefer a
library solution but your pull request seems to go for a in-compiler solution.

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

There is no intent to cover infinite forward ranges with default behavior.
Again, the primary goal here should be, I think, to make code defining casual
ranges easy and boilerplate-free. Infinite ranges or ranges that don't define
length yet want to define slicing through to the end are comparatively rare. It
is reasonable to request people defining those to define opDollar
appropriately.

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

If we go for a library solution, we should define opDollar in object.d so it's
available by default. It should look something like this (in the 1-dimensional
case):

    auto ref opDollar(R)(auto ref R r) if (is(typeof(r.length))) {
        return r.length;
    }

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