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

Subject: Re: [boost] [Review:Algorithms] Order of args to clamp
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-09-26 10:16:45

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