Transient ranges

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

I don't think that should be a huge problem, but after having 
looked at the compiler code [1]: we should name it neither front 
nor popFront, because how would the compiler know that it is 
supposed to be transient and not a normal InputRange without 
front or popFront for which it should throw an error?

Idea 1: New name that will make it easier to distinguish that 
transient ranges are something completly different to normal 
ranges.
How about next?
Problem 1: One can't use algorithms that work on transient ranges 
(map, reduce) anymore

Idea 2: Help the compiler with @Transient or `enum transient = 
true`
Problem 2: How would the "transientivity" be automatically 
forwarded to ranges that work on it.

Btw thinking longer about it - transient ranges aren't bad per 
se. They objey the InputRange contract and e.g. the following 
works just fine. It's just impossible to distinguish between a 
transient and a non-transient InputRange.

```
// input: 1\n2\n\3\n4\n...
void main()
{
     import std.stdio, std.conv, std.algorithm;
     stdin
         .byLine
         .map!((a) => a.to!int)
         .sum
         .writeln;
}
```

https://github.com/dlang/dmd/blob/master/src/statement.d#L2596