Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-22 13:32:27

Mathias,

> This is a bad explanation which can prove misleading.
>
> The reason why you think Boost.Range is broken is because iterator_range 
> (which is nothing more than a fancy std::pair, I never found the use of 
> it myself) used to allow operations such as "empty" on an uninitialized 
> range but doesn't anymore.

In that case I feel that it is not appropriate for you to say that my
explanation is "bad or misleading".  I've given facts based on actual extended
usage.  You have just attacked the explanations without providing any.  

> If it was just me, default-constructing iterators and ranges shouldn't 
> even be allowed (unless that is sufficient that initialize it).
> A range that is not properly initialized is not in any usable state. 

This purely depends on how you design and document your range class.  You have
one opinion, I have another.  My real qualm isn't with the new behaviour - I
wouldn't be as presumptuous as to assume that everyone would like to use
Boost.Range in the same way I do - the problem is with how the behaviour was
changed and that real functionality was removed which has no replacement.  If
you recall, I proposed that both variants live in Boost.

> It's not an empty range, it's more like a pointer to somewhere random. 

This is not the case - there are plenty of iterators which have valid semantics
when default constructed, including some in the standard library.

> Just don't try to use it. If Boost.Range used to allow it, that was a 
> bug; good thing it is now fixed.

That's not an answer - I've written an entire suite of generic libraries that
depend on this (documented!) behaviour.  You are not a Boost.Range user, that's
why you haven't been affected by this issue.

> As for is_singular, that function shouldn't be exposed to the public.

That's one thing we can agree on.

Tom