sqrt(2) must go

dsimcha dsimcha at yahoo.com
Wed Oct 19 11:12:51 PDT 2011


== Quote from Don (nospam at nospam.com)'s article
> 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.

No.  Something as simple as sqrt(2) must work at all costs, period.  A language
that adds a bunch of silly complications to something this simple is fundamentally
broken.  I don't remember your post on implicit preferred conversions, but IMHO
implicit conversions of integer to double is a no-brainer.  Requiring something
this simple to be explicit is Java/Pascal-like overkill on explicitness.


More information about the Digitalmars-d mailing list