Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 5/27/16 9:48 PM, Jonathan M Davis via Digitalmars-d 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. Every
> single range-based function would have to either test that the "transient"
> enum wasn't there or take transient ranges into account, and realistically,
> that isn't going to happen. For better or worse, we do have byLine in
> std.stdio, which has a transient front, but aside from the performance
> benefits, it's been a disaster.

Wholly disagree. If we didn't cache the element, D would be a 
laughingstock of performance-minded tests.

> It's way too error-prone. We now have
> byLineCopy to combat that, but of course, byLine is the more obvious
> function and thus more likely to be used (plus it's been around longer), so
> a _lot_ of code is going to end up using it, and a good chunk of that code
> really should be using byLineCopy.

There's nothing actually wrong with using byLine, and copying on demand. 
Why such a negative connotation?

> I'm of the opinion that if you want a transient front, you should just use
> opApply and skip ranges entirely.

So you want to make this code invalid? Why?

foreach(i; map!(a => a.to!int)(stdin.byLine))
{
    // process each integer
    ...
}

You want to make me copy each line to a heap-allocated string so I can 
parse it?!!

> Allowing for front to be transient -
> whether you can check for it or not - simply is not worth the extra
> complications. I'd love it if we deprecated byLine's range functions, and
> made it use opApply instead and just declare transient ranges to be
> completely unsupported. If you want to write your code to have a transient
> front, you can obviously take that risk, but you're on your own.

There is no way to disallow front from being transient. In fact, it 
should be assumed that it is the default unless it's wholly a value-type.

-Steve