Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-11-23 16:13:56

On Sun, Nov 23, 2008 at 2:46 PM, Thorsten Ottosen
<thorsten.ottosen_at_[hidden]> wrote:
> Daniel Walker skrev:
>>
>> On Sun, Nov 23, 2008 at 1:37 AM, David Abrahams <dave_at_[hidden]> wrote:
>>>
>>> on Sat Nov 22 2008, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org>
>>> wrote:
>>>
>>>> iterator_range (which is nothing more than a fancy std::pair, I never
>>>> found the use of it myself)
>>>
>>> It's a bit less redundant to write the type name, since both members of
>>> the pair have to be the same, and it has a little more communicative
>>> power,
>>> since after all pair<Iter,Iter> doesn't have to represent a range; it
>>> has only been retroactively adapted to model Range when p.second is
>>> reachable from p.first.
>>>
>>> So, not completely useless, IMO.
>>
>> This is a good point, and I'm a big fan of expressivity and
>> self-documenting code. iterator_range is a much better name for a
>> range than "pair", and it's also good that iterator_range has only one
>> template parameter for the type of iterator. I guess what turned me
>> off of it was its bulkiness with all those methods sticking out of it
>> in every direction.
>
> Daniel,
>
> Wrt. the new range concepts, then I only changed those so they would match
> the new concept requirements, after the second version of the library took
> its form. I think that was the only sensible thing to do.
>
> best regards
>
> -Thorsten

In the documentation, the Range concept definitions (which I believe
were reviewed for release in 1.32) included a requirement for empty(r)
that I believe would help clear up some of the problems that initiated
this discussion. This requirement is independent of any particular
class including the classes supplied by Boost.Range, that's the beauty
of concepts. Stripping the concepts in response to changes in
iterator_range undermines the whole abstraction and has made
Boost.Range less usable, IMHO. I think the boost formal review process
lead to a higher quality of library concept definitions in release
1.32 than those available in the current release.

Daniel Walker