sqrt(2) must go

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


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


More information about the Digitalmars-d mailing list