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

Reply via email to