sqrt(2) must go

Alex Rønne Petersen xtzgzorex at gmail.com
Wed Oct 19 09:25:48 PDT 2011


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


More information about the Digitalmars-d mailing list