Tricky semantics of ranges & potentially numerous Phobos bugs
Jonathan M Davis
jmdavisProg at gmx.com
Tue Oct 16 12:21:11 PDT 2012
On Tuesday, October 16, 2012 12:07:01 H. S. Teoh wrote:
> Perhaps mark ranges with an .isTransient property (which can be an enum
> so it doesn't waste any space), and range-based functions that require
> non-transient ranges will refuse to work with a transient range. Or
> alternatively, switch to a different implementation that takes
> transience into account (which may be slower, etc., but the important
> thing is to do it right -- after all, D's motto is safe by default,
> unsafe if you ask for it).
Not a bad idea, though it's still arguably a bit disgusting to potentially
have to check for that all over the place. Inevitably, most functions won't
check, and ByLine _still_ won't work. Yes, Phobos would presumably end up
checking in most cases, but I suspect that little else will. We arguably have
way to many things to check about ranges as it is. So, I'd be far more tempted
to just change ByLine to use opApply rather than adding the extra complication
of isTransient to the standard library just for this one use case.
> I think this approach of what amounts to guessing which ranges are
> safe/unsafe with which functions is what's untenable. We all know that
> people don't read documentation, or at least, not thoroughly. Something
> like this is too easy to miss, and bugs will slip into code unnoticed
> for a long time, and then explode in your face. It's unsafe by default,
> which goes against D's philosophy.
The problem is that what ByLine is doing is incredibly abnormal. So, we're
talking about affecting how all ranges do things just to satisfy one,
incredibly abnormal use case. It's just that this one range is heavily used,
making the fact that it doesn't work normally a problem. But given that even
using opApply with ByLine would require the programmer to understand how to
use it correctly (since simply keeping the buffer around after an iteration
would still break in that case), the programmer has to understand the
weirdness of ByLine _regardless_, making it so that I don't know that it's
ultimately all that big a deal that many range-based functions will choke on
it. The main problem I see with that is similar to the problem with relying on
CTFE - a simple change to a function could make it so that what _did_ work
correctly suddenly stops working correctly and will only be caught if that
particular use case has unit tests (highly unlikely with ByLine).
So, really, I'm in favor of just making ByLine use opApply and make it so that
it's not a range. That doesn't completely fix the problem, but it reduces its
scope and doesn't complicate the rest of Phobos in the process.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list