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