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.
