Transient ranges

[ZombineDev 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:
>> 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.

Scratch that:

> 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.

This won't work safely, because the compiler would need to 
disallow access to the previous instance of the range (sort of 
Rust moved-from objects), but it's currently no possible.

I proposed that idea because I have other uses for immutable 
ranges, unrelated to this discussion.