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