Transient ranges

[Steven Schveighoffer via Digitalmars-d]

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