sqrt(2) must go

[Don]

On 19.10.2011 20:12, dsimcha wrote:
> == 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.

Where the hell were you when I made that proposal before?
Frankly, I'm pissed off that you guys bullied me into putting an *awful* 
temporary hack into std.math, and then gave me no support when the idea 
got shouted down on the ng.

> 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.

The bottom line: the hack MUST go. Either we fix this properly, as I 
suggested, or else it must not compile.