[boost] Is Boost.Range broken?

Subject: [boost] Is Boost.Range broken?
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-21 17:09:08

I decided to split off this part of another thread to try to get a consensus on
the changes that occurred in Boost.Range with boost 1.35.  The background is
discussed elsewhere.  What I'd like to do here is to come to an agreement with
Thorsten and other developers on the following issues:

1) Is the change in the behaviour of Boost.Range in fact a defect?
2) What should be done about it?

Here are the reasons why I think Boost.Range is broken:

1) Empty ranges are useless and they cannot even be reliably tested for
emptiness.  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.  In addition, this is not documented well
and can lead to subtle bugs and undefined behaviour, which will only manifest
itself in release builds.
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.
3) Reintroducing the "singular" member into release builds to make the
is_singular() function work correctly will defeat the purpose of the size
optimisation, while still not achieving interface compatibility with
std::containers.
4) Having the additional if() condition in size() and empty()is unlikely to be a
large burden on most programs.  I would expect most programs will spend more
time iterating data than testing ranges for emptiness.
5) The change could be reverted without affecting users.  For those who are
relying on the new behaviour, the change to empty() and size() should be
immaterial, as they cannot be calling them now on singular ranges anyway.

My proposed fix would be the following:

Roll back iterator_range to the pre-1.35 release state immediately.

For a future release, create a new class, boost::simple_range which has the
behaviour of the new version (i.e. no singular member).  Publicly derive
iterator_range from simple_range and provide additional factory functions such
as make_simple_range().

I would appreciate any feedback on this issue.

Kind regards,

Tom