sqrt(2) must go

[Marco Leise]

Am 19.10.2011, 18:25 Uhr, schrieb Alex Rønne Petersen  
<xtzgzorex at gmail.com>:

> On 19-10-2011 18:22, Alex Rønne Petersen wrote:
>> On 19-10-2011 18:18, Don wrote:
>>> In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's
>>> ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also
>>> applies to _any_ function which has overloads for more than one  
>>> floating
>>> point type.
>>>
>>> In D2 between versions 2.049 and the present, sqrt(2) compiles due to
>>> the request of a small number of people (2-3, I think). But still, no
>>> other floating point function works with integer literals.
>>>
>>> The "bug" being fixed was
>>> Bugzilla 4455: Taking the sqrt of an integer shouldn't require an
>>> explicit cast.
>>>
>>> This compiles only due to an awful, undocumented hack in std.math. It
>>> doesn't work for any function other than sqrt. I protested strongly
>>> against this, but accepted it only on the proviso that we would fix
>>> integer literal conversions to floating point in _all_ cases, so that
>>> the hack could be removed.
>>>
>>> However, when I proposed the fix on the newsgroup (integer literals
>>> should have a preferred conversion to double), it was *unanimously*
>>> rejected. Those who had argued for the hack were conspicuously absent.
>>>
>>> The hack must go.
>>>
>>
>> What on earth does it matter? It's just a cast. And when typing out
>> floating-point literals, it *really* does not hurt to type 2.0f instead
>> of 2. In .NET land, people live with this just fine (see
>> System.Math.Sqrt). Why can't we?
>>
>> I say kill the hack.
>>
>> - Alex
>
> PS: What's wrong with converting integer literals to double? It's a  
> lossless conversion, no?
>
> - Alex

As long as it is not a 64-bit integer, yes.
More philosophical, I think integer math should be separate from FP math,  
because it has different semantics (integer division with remainder,  
overflow vs. infinity, fixed steps vs. exponent, shifting, ...). So I  
think .NET handles this correctly. But converting 32-bit ints to double  
shouldn't harm much either. JavaScript has no integers, only doubles. It  
works.
When you come across a for loop there and think to yourself "it increments  
a variant that stores a double there", you can laugh or cry. (Actually  
good JS engines optimize that case, of course.)