Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-11-21 20:28:25

On Fri, Nov 21, 2008 at 17:09, Tomas Puverle
<Tomas.Puverle_at_[hidden]> wrote:
> 1) Empty ranges are useless and they cannot even be reliably tested for
> emptiness.

No, empty ranges are useful and can be reliably tested.

> The empty() function now asserts and the is_singular() function
> behaves differently between debug and release builds, making it impossible to
> detect if a range is, in fact, empty.

Yes, singular ranges are almost useless, and cannot be tested for
singularity.  This seems reasonable, as it's just like ints and
iterators.  I wouldn't say that a singular range is empty, just as I
wouldn't say that an uninitialized int has a value.

I would agree that is_singular should not be available at all in
release builds, if it's never useful there.  I'd consider it analagous
to iterator debugging features, and would think it might be exposition
only.

> In addition, this is not documented well
> and can lead to subtle bugs and undefined behaviour, which will only manifest
> itself in release builds.

But what semantics for empty *are* documented?

http://www.boost.org/doc/libs/1_37_0/libs/range/doc/boost_range.html#Semantics
empty(x) returns boost::begin(x) == boost::end(x)

That's undefined when begin and end return singular iterators, so I'm
not convinced that the "singular implies empty" behaviour was ever
documented.  (The "returns" entry for empty is the same for 1_36_0,
1_35_0, 1_34_0, and 1_33_1.)

> 2) The behaviour is unintuitive.  Range is a generalisation of the interface of
> the std::containers.  With this change, containers and ranges can no longer be
> used in the same code path.

Why would you ever want to pass a default-constructed range to anything?