Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-08 16:12:17

on Fri Oct 07 2011, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:

> Dave Abrahams wrote:
>> on Fri Oct 07 2011, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
> ...
>> > The current specification (ignoring the conversion issue for now, as
>
>> > it's separate) says:
>> >
>> > - when T is EqualityComparable, returns the first element that
>> > equals > value;
>> > - otherwise, returns the first element *i for which *i == value.
>> >
>> > Your preferred replacement says:
>> >
>> > - when T is EqualityComparable, returns the first element that
>> > equals > value;
>> > - otherwise, the behavior is undefined.
>> >
>> > Do tell me why it's better.
>>
>> Well, if you phrase it that way, it's a little different.  The original
>> description only had the "otherwise" clause, right?
>
> Yes. The "otherwise" clause implies the preceding clause when T is
> EqualityComparable. I wrote it that way to highlight the fact that the
> two specifications only differ in the "otherwise" part.

Yes, they differ in *consequence* only in the "otherwise" part.  But you
would never write the first one that way since the first part is
logically redundant and thus needlessly complicating, and you would
never write the second one that way for reasons already stated.  It's a
question of emphasis.  The first one emphasizes implementation details
and the second one emphasizes the abstraction represented by the
algorithm.

[All that said, I see your point; I'm not rigid about this... but, do
you see mine?]

>> The "replacement" is still simpler, because you wouldn't actually write
>> the "otherwise ..." clause; you just say it requires EqualityComparable.
>
> It may be simpler, but why is it better? 

Err,... because it's simpler? ;-)

If you take this to an extreme, you end up exposing the entire
implementation of the algorithm *as* its specification, and telling the
user, "if you want to know what this does on a set of models of the
usual concepts, figure it out yourself."

> People who operate on properly EqualityComparable types see no
> difference between the two, whereas people whose op== isn't, for some
> unfathomable reason, an equivalence relation still get the expected
> result from the first and undefined behavior from the second.

I agree that the use cases being described are interesting, intuitive,
and useful, and I have a hard time with the idea that we shouldn't
support them.

Maybe it makes sense to start writing things in the way you have above,
so that the pure concepts are redundantly handled in the specification.
But I'm still very uneasy about any specification that looks like it's
exposing the implementation details.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com