Tricky semantics of ranges & potentially numerous Phobos bugs

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Oct 17 11:09:32 PDT 2012


On 10/17/12 12:53 PM, H. S. Teoh wrote:
> On Wed, Oct 17, 2012 at 12:39:13PM -0400, Andrei Alexandrescu wrote:
>> On 10/16/12 1:28 PM, Jonathan M Davis wrote:
>>> So, it's fine that ByLine is a range as long as we're willing to put
>>> up with it not working with a lot of range-based functions because of
>>> its abnormal behavior. But I don't think that it's at all reasonable
>>> for range-based functions in general to not be able to rely on front
>>> returning the same type every time or on its value disappearing or
>>> becoming invalid in some way after a call to popFront. That's
>>> completely untenable IMHO.
>>
>> Then what is to you the difference between an input range and a
>> forward range?
> [...]
>
> So what you're saying, is that we cannot rely on the value of .front
> after popFront() is called, and that the only way to ensure the validity
> of .front is to use a forward range's .save, and access the saved copy's
> .front?

Affirmative.

> It makes sense to me, but then we'd need to revise quite a lot of code
> in Phobos, as I've seen quite a number of places where .front is cached
> in some local variable or struct field, which would be invalid by your
> definition.

Yes. Only code that ostensibly works with input ranges needs to be reviewed.


Andrei


More information about the Digitalmars-d mailing list