Transient ranges

[Seb 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?

Nothing. Just that it could lead to a lot of surprising mistakes, 
currently the following yields an error:

struct A
{
    auto front(){ ...}
    enum empty = false;
}
A as;
foreach (a; as) {} // ERROR: no method popFront found

with the proposed change it would compile.