On Thu, 20 Oct 2011 15:52:35 +0200, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Thu, 20 Oct 2011 09:11:27 -0400, Don <nos...@nospam.com> wrote:
Actually there is a problem there, I think. If someone later on adds
NotOverload(double x), that call will suddenly stop compiling.
That isn't just a theoretical problem.
Currently log(2) will compile, but only because in std.math there is
log(real), but not yet log(double) or log(float).
So once we add those overloads, peoples code will break.
Should there be a concern over silently changing the code path? For
instance, log(2) currently binds to log(real), but with the addition of
log(double) will bind to that.
I'm not saying I found any problems with this, but I'm wondering if it
can possibly harm anything. I don't have enough experience with
floating point types to come up with a use case that would be affected.
-Steve
I think you're right. The biggest implication is not lossless conversion
of integers but what's actually calculated.
With transcendental math functions the return type usually matches the
input type.
When you change cos(2) from real to double this might be an issue.
As long as the compiler constants keep full precision this might be okay.
But it definitely rules out to chose double overloads for non-literal
integers,
as it looses precision and adds a store and load to convert the returned
real to double.
martin