Transient ranges

[default0 via Digitalmars-d]

On Sunday, 29 May 2016 at 11:36:37 UTC, ZombineDev 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:
>>> 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.

Isnt the idea to communicate "hey! You may not possibly cache 
whatever value you get in an iteration"? If yes, just removing 
.front seems odd as, well, I can still obviously just cache the 
result of .popFront if I'm inexperienced with ranges. Maybe 
instead simply rename .front to .buffer for transient ranges? 
That name would more accurately convey that this is just a buffer 
the range uses to dump the current front value in, but that if 
you want to cache it you will need to duplicate it (because, hey, 
this is the buffer of the range, not yours).

Not sure this is a great idea or a great name, but simply 
removing .front and returning the current iteration value from 
.popFront imho does not convey "you should not expect to be able 
to simply cache this by assignment" to me - arguably this is not 
a problem since how transient ranges work would be a documented 
thing, but thats just my 2 cents.