http://d.puremagic.com/issues/show_bug.cgi?id=7177
--- Comment #52 from [email protected] 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: -------
