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.
