Transient ranges

[ZombineDev via Digitalmars-d]

On Sunday, 29 May 2016 at 15:45:14 UTC, Joseph Rushton Wakeling 
wrote:
> On Sunday, 29 May 2016 at 11:28:11 UTC, ZombineDev wrote:
>> On Sunday, 29 May 2016 at 11:15:19 UTC, Dicebot wrote:
>>> 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.
>
> I don't follow your reasoning here.  In the proposal I put 
> forward, if a range doesn't define `popFront()`, it's not an 
> InputRange, it's a TransientRange.
>
> Conversely, if it _does_ define `popFront()`, it _is_ an 
> InputRange.
>
> What's the problem with introspecting that?

Yes it can be introspected in library, but it breaks the 
expectations of the unsuspecting user. For example:

auto r = getSomeRange();

assert (r.front == r.front);

So, under your suggestion, the above could fail just because an 
implementation detail was changed like modifying some input range 
to become a transient range and somehow the code still compiled.

Now I'm leaning more towards the buffer + popFront + empty trio, 
because it's harder to misuse.

An alternative would be tagging such ranges with an enum or UDA, 
but we would need to verify/change too many places in phobos for 
this to work.