Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 5/29/16 7:28 AM, ZombineDev wrote:
> On Sunday, 29 May 2016 at 11:15:19 UTC, Dicebot wrote:
>> On 05/28/2016 08:27 PM, Joseph Rushton Wakeling wrote:
>>> On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis wrote:
>>>> On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
>>>>> So what about the convention to explicitely declare a `.transient`
>>>>> enum member on a range, if the front element value can change?
>>>>
>>>> Honestly, I don't think that supporting transient ranges is worth it.
>>>
>>> I have personally wondered if there was a case for a TransientRange
>>> concept where the only primitives defined are `empty` and `front`.
>>>
>>> `popFront()` is not defined because the whole point is that every
>>> single call to `front` will produce a different value.
>>
>> I would prefer such ranges to not have `front` and return new item
>> from `popFront` instead but yes, I would much prefer it to existing
>> form, transient or not. It is impossible to correctly define input
>> range without caching front which may not be always possible and may
>> have negative performance impact. Because of that, a lot of Phobos
>> ranges compromise `front` consistency in favor of speed up - which
>> only seems to work because most algorithms need to access `front` once.
>>
>> I believe this is biggest issue in D ranges design right now, by large
>> margin.
>
> +1
> I think making popFront return a value for transient ranges is a sound
> idea. It would allow to easily distinguish between InputRange and
> TransientRange with very simple CT introspection. The biggest blocker is
> to teach the compiler to recognize TransientRange types in foreach.

This doesn't help at all. I can still make a "transient" range with all 
three range primitives.

There seems to be a misunderstanding about what a transient range is.

byLine is a transient range that requires the front element be cacheable 
(I have to build the line somewhere, and reusing that buffer provides 
performance). Shoehorning into a popFront-only style "range" does not 
solve the problem. Not only that, but now I would have to cache BOTH the 
front element and the next one.

-Steve