Transient ranges

[cym13 via Digitalmars-d]

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. 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. 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.
>
> I'm of the opinion that if you want a transient front, you 
> should just use opApply and skip ranges entirely. 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.
>
> - Jonathan M Davis

Agreed, any time I see « you're code is wrong, byLine reuses its 
buffer you should use byLineCopy instead » I cringe as it means 
that people are supposed to know implementation details. It's 
obviously a leaky abstraction. While its speed makes it useful 
nonetheless I don't think such code should be encouraged.