Transient ranges

[Joseph Rushton Wakeling via Digitalmars-d]

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?