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.
