on Mon Sep 26 2011, Andrew Sutton <asutton.list-AT-gmail.com> wrote:
Fair enough; it is a natural requirement to start with given the "obvious" implementation using conditionals.
Yeah, but now we're back at implementation-driven requirements.
Right, but all type requirements are implementation-driven.
Doh! I knew there was something wrong with that when I wrote it :-P.
We just shouldn't state them in terms of the implementation.
You're right of course.
clamp(x, lo, hi)
and
clamp((U)x, (U)low, (U)hi)
should give the same result.
...right... so now should every algorithm be generalized that way, with the attendant complications in specification? Do we need the same interface for, say, GCD? Why not just ask the caller to cast to the common type first?
Good question. There seems to be a lot of precedence in the std library for multi-type generalization.
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.
I'm not suggesting that this is good or bad, only a decision to be considered. Unifying type arguments leads to much simpler requirements at the cost of generality and, as Phil demonstrates, performance.
Maybe. * We're not talking about a big-O difference here * the size of Phil's test wasn't compelling to me * With a single-type clamp, nobody who cared about performance would write it the way Phil wrote it; they'd hoist the conversion to string. Is there a real-world use-case where we're clamping heterogeneous types and all three values are changing?
Generalization gets us into these discussions.
And, since turn-about is fair play... Generalization should be use-case-driven, no? -- Dave Abrahams BoostPro Computing http://www.boostpro.com