Re: [boost] [Review:Algorithms] Order of args to clamp

Subject: Re: [boost] [Review:Algorithms] Order of args to clamp
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-09-26 11:38:38

>> Generalization gets us into these discussions.
>
> And, since turn-about is fair play... Generalization should be
> use-case-driven, no?

Well said, sir :)

> Yes, but the std library's concept requirements are too loose.  If we
> had had concepts in the language, against which we could check the
> specification, when the STL was first implemented, that wouldn't have
> happened.  But maybe it would be a good time to ask you to list some
> examples from std, so we can talk in terms of specifics.

We could talk about find() because its so obvious.

template<typename I, typename T>
I find(I first, I last, T const& value) {
  for( ; first != last; ++first) {
    if(*first == value) return first;
  }
  return last;
}

The == falls under the same topic of discussion as < for clamp. For
different, unrelated types, what meaning can you possibly assign to
the expression. The same reasons apply. Equality is reflexive,
symmetric, and transitive, and should probably define real equality
and not just an equivalence relation. Try showing that == on unrelated
types satisfies the reflexive property.

You could require that T and the value type be the SameType, but
that's really strict. You could replace T with
iterator_traits<I>::value_type to unify the types; EqualityComparable
is meaningfully applied to a single type instead of the incredibly
vague and meaning-free HasEqual. This allows conversion, but at a
small cost of performance. If generality is needed, you could phrase
requirements in terms of common type, like we've done in this
discussion.

I don't think that any solution is inherently better than any other;
except with respect to the use cases that you need it to satisfy. EoP
takes the first approach because the language in the book doesn't deal
with conversions. I think the second is a reasonable since it allows
requirements to be stated clearly and simply. I think the last is fine
because it is both general and precise, although the exact
requirements might be harder to state.

We could have similar discussions for every algorithm where there are
two value types involved in an expression. I'd guess that this is
60-70% of all the STL algorithms?