C++Now! 2012 slides

[Peter Alexander]

On Thursday, 7 June 2012 at 21:22:57 UTC, Timon Gehr wrote:
> There is not much there to clutter in this case. Therefore 
> cluttering
> does not have a significant drawback. Is it just about 
> aesthetics?

Aesthetics is part of it, but it's more than that.

It makes the code more difficult to read. I would need to step 
through the definition of MinType to find out what min(uint, int) 
returns.

It adds to compile times and compiler memory usage (it all adds 
up...)

It adds more code paths that need to be tested/debugged. Bugs 
like this for example: 
http://d.puremagic.com/issues/show_bug.cgi?id=8158 (note: it 
compiles with my simple min). Also note how the error message 
leaks all the clutter from min, making it difficult to tell 
exactly what the error is. There would be no complicated errors 
from my version, no matter what you did.

It makes it difficult to reason about how different types work 
with the function (e.g. with Date). With the complicated version 
in std.algorithm I have to now worry about what isIntegral 
returns for my type, and what mostNegative returns. If I create a 
BigInteger type and a BigUnsignedInteger type, how do I make sure 
it works correctly if I use those two as arguments to min? I'm 
sure the answer is simple, but finding that answer is non-trivial.


>> 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.

Good spot on the stability.

There's nothing wrong with a strict superset, we just have to 
admit that there is a non-zero cost to this extra generality. I 
have listed some of the costs above. Some are arguable, but it is 
inarguable that at least one bug has arisen as a direct result of 
its complexity. I suspect there will be more over time. Multiply 
that with all the functions that try to be excessively general.