Transient ranges

[Joseph Rushton Wakeling via Digitalmars-d]

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.