sqrt(2) must go

[Martin Nowak]

On Thu, 20 Oct 2011 15:52:35 +0200, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Thu, 20 Oct 2011 09:11:27 -0400, Don <nospam at 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