Many architectures do not support real, and therefore it should never be used implicitly by the language.
Precision problems aside, I would personally insist that implicit conversation from any sized int always be to float, not double, for performance reasons (the whole point of a compiled language trying to supersede C/C++). Amusingly, 5_000_000_000 IS actually precisely representable with a float ;) .. Bet let's take 5_000_000_001, it'll lose a few bits, but that's more than precise enough for me. Naturally the majority would make solid arguments against this preference, and I would agree with them in their argument, therefore should it not just be a compiler flag/option to explicitly specify the implicit int->float conversion precision? Though that leads to a problem with standard library, since it links a pre-compiled binary... I can't afford to have the standard library messing around with doubles because that was the flag it was compiled with... This leads inevitably to my pointlessly rewriting the standard library functions in my own code, just as in C where the CRT uses doubles, for the same reasons... On 20 October 2011 06:01, Steven Schveighoffer <schvei...@yahoo.com> wrote: > On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques <sandf...@jhu.edu> > wrote: > > On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise <marco.le...@gmx.de> >> wrote: >> >>> Am 20.10.2011, 02:46 Uhr, schrieb dsimcha <dsim...@yahoo.com>: >>> >>> On 10/19/2011 6:25 PM, Alvaro wrote: >>>> >>>>> El 19/10/2011 20:12, dsimcha escribió: >>>>> >>>>>> == Quote from Don (nos...@nospam.com)'s article >>>>>> >>>>>>> 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. >>>>>> >>>>> >>>>> Completely agree. >>>>> >>>>> I call that uncluttered programming. No excessive explicitness should >>>>> be >>>>> necessary when what you mean is obvious (under some simple >>>>> conventions). >>>>> Leads to clearer code. >>>>> >>>>> >>>> Yes, and for the most part uncluttered programming is one of D's biggest >>>> strengths. Let's not ruin it by complicating sqrt(2). >>>> >>> >>> What is the compiler to do with sqrt(5_000_000_000) ? It doesn't fit into >>> an int, but it fits into a double. >>> >> >> Simple, is a 5_000_000_000 long, and longs convert to reals. Also, >> 5_000_000_000 does not fit, exactly inside a double. >> > > It doesn't? I thought double could do 53 bits? > > Although I agree, long should map to real, because obviously not all longs > fit into a double exactly. > > -Steve >