Transient ranges

[ZombineDev via Digitalmars-d]

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.

Another option is to make popFront return a new range, ala 
slice[1..$] (like std.range.dropOne) which would have the benefit 
of allowing const/immutable ranges to work.