On 06/07/2012 10:53 PM, Peter Alexander wrote:
On Thursday, 7 June 2012 at 20:04:56 UTC, Timon Gehr wrote:
On 06/07/2012 08:34 PM, Peter Alexander wrote:
I find this very ugly. To be honest, I would be much happier without all
that mostNegative and common type stuff.
If I want to get the min
between a short and an int I'll just cast them appropriately.
The mostNegative and common type stuff is there to enable correct
semantics for taking the minimum of signed and unsigned values.
Minimum of short and int would work fine without that.
I know what it's there for, I don't think it is necessary. I don't think
people should be taking the min of signed and unsigned values.
What is important is that they can. ;)
I don't think it's worth cluttering the implementation for this minor
convenience.
There is not much there to clutter in this case. Therefore cluttering
does not have a significant drawback. Is it just about aesthetics?
I'd much rather have a simpler standard library than a complicated
one for the
sake of a little convenience.
'min' is not complicated.
It's more complicated than it could/should be:
T min(T)(T x, T y) { return x < y ? x : y; }
This implementation is unstable. If you fix that, then I'll agree that
it is sufficient for most cases. There is not really a reason to
restrict the generality of the implementation to this though. What we
have is a strict superset.
To be honest, I don't think the variadic argument versions are necessary
either as it is just duplicating the functionality of reduce.
It is not really duplicating the functionality. Still, I haven't used
these versions so far either.
