Re: [boost] [Boost-users] Maintenace Guidelines wiki page

Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page
From: Peter Bartlett (pete_at_[hidden])
Date: 2008-11-26 04:30:06

Quoting Daniel Walker <daniel.j.walker_at_[hidden]>:

> On Tue, Nov 25, 2008 at 1:57 AM, John Phillips
> <phillips_at_[hidden]> wrote:
>> Daniel Walker wrote:
>>> In general, no, but in this specific instance, yes. At least, the
>>> Range concept definitions in the initial release immediately following
>>> the formal review are richer and more useful, IMHO, than the
>>> definitions available in the current release.
>>
>>  I spent some time with the archives this evening, and I find that there are
>> dozens of emails from 2005, 2006, and 2007 talking about problems with the
>> concept definitions and documentation in the original version of the range
>> library. I also found a couple of different threads where Thorsten requested
>> advice on potential changes to the library, and where he announced breaking
>> changes to the library as a result of those conversations.
>
> I just did a search and found nothing. But good grief, let's not put
> each other on trial. Let's put the code, the designs and the
> development policies on trail.
>
> We have two specifications for the Range concepts that we can
> (objectively) compare. I maintain that the specification released
> after the formal review is clearly richer, offers more abstraction,
> and is more useful than the concepts available in the current release.
> In this instance, the changes in the library's concept definitions
> have resulted in a decrease in expressiveness and usability. The
> library would have benefited from guidelines aimed at stabilizing the
> initial release.
>
>>  So, though you may have preferred the old concepts, others thought them
>> fatally flawed (and I find their arguments persuasive).
>
> If it's so fatal, name one problem that results from empty(r) being
> included in the Range concepts.
>
>>  This is not to say that I think the changes that started this thread were
>> made properly. I can find no discussion on the developer list or note in the
>> documentation about the changes happening, and I think that is a minimal
>> standard for breaking changes. However, they may have been part of a
>> redesign that was precipitated by conversations on the developer list, and
>> other parts of that work were announced and discussed on the list. This
>> would imply that Thorsten was closer to an acceptable process than he is
>> currently getting credit for.
>
> Look, throwing blame this way and that is not going to get anywhere,
> and I apologize for ever adopting an accusatory tone. I was rather
> offended at the state of the Range concepts, and I may not have always
> used particularly diplomatic language. Then again, I consider candor
> to be courteous and a sign of respect. So, I'm not going to beat
> around the bush.
>
> Let's stick to the facts. The Range concept definitions went from
> supporting up to 6 procedural abstractions (begin(r), end(r),
> empty(r), size(r) rbegin(r), rend(r)) to supporting 2 (begin(r),
> end(r)). I would call that a 66% reduction in expressiveness. So I
> repeat, the Range concept definitions in the initial release
> immediately following the formal review are richer and more useful
> than the definitions available in the current release.
>
> More over, the current state of the Range concepts is indefensible. At
> least, no one has offered a defense. More specifically, no one has
> offered a response to the question of what problem is solved or what
> benefit is gained by removing empty(r) from the concept definitions. I
> gave a lengthy argument last night as to the benefits of empty(r). No
> one has countered it. Why should they? Emptiness or non-emptiness are
> natural, obvious attributes of a range. Why shouldn't a range
> abstraction such as a generic concept include a method for querying
> emptiness? It only makes sense.

Re "no-one has offered a defense". that could be because some of us  
(well me, at least) are confused about the how big a problem you think  
we we have. Are you saying you _can't_ check for emptiness with the  
current requirements? But doesn't  
boost::empty<SomeTypeModellingSinglePassRange>(r) do exactly that
(http://www.boost.org/doc/libs/1_37_0/libs/range/doc/boost_range.html)?

If you were arguing solely about possible performance loss by not  
allowing a type to implement its own empty then I'd understand, but  
you don't seem to be saying that.