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