[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

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



--- Comment #52 from monarchdodra at gmail.com 2013-03-25 03:53:11 PDT ---
(In reply to comment #50)
> 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.

Well, I think the compiler can't do *everything* for the user. If you want an
infinite range to adhere to "hasSlicing", then at the very least, it has to
implement the slicing primitive.

The notion of "slice-able infinite range" has always been ambiguous, but IMO,
"slice to end" primitive is the important one that *must* be implemented and
checked. I'd doubt we'd break much code enforcing this.

Besides, at worst, ranges that can't be sliced to end would seize being
considered sliceable, which, IMO, is a good thing anyways.

I think we should make this change (for which there would be no automatic
workaround) sooner rather than later.

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