On 6/1/16 8:49 AM, Joseph Rushton Wakeling wrote:
On Tuesday, 31 May 2016 at 18:31:05 UTC, Steven Schveighoffer wrote:
On 5/31/16 11:45 AM, Jonathan M Davis via Digitalmars-d wrote:
On Monday, May 30, 2016 09:57:29 H. S. Teoh via Digitalmars-d wrote:
I'd argue that range-based generic code that assumes non-transience is
inherently buggy, because generic code ought not to make any
assumptions beyond what the range API guarantees. Currently, the range
API does not guarantee non-transience, therefore code that assumes
so is
broken by definition. Just because they happen to work most of the
time
does not change the fact that they're written wrongly.
Technically, the range API doesn't even require that front return the
same
value every time that it's called, because isInputRange can't
possibly test
for it.
The API doesn't require it mechanically, but the API does require it
semantically (what does popFront mean if front changes
automatically?). If front returns different things, I'd say that's a
bug in your range construction.
The `Generator` range is an eager violator of this requirement:
https://github.com/dlang/phobos/blob/ca292ff78cd825f642eb58d586e2723ba14ae448/std/range/package.d#L3075-L3080
.... although I'd agree that's an implementation error.
Yeah, that seems like a bug.
-Steve
