On 20.10.2011 05:01, Steven Schveighoffer 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
But ulong.max does NOT fit into an 80-bit real. And long won't fit into
real on anything other than x86, 68K, and Itanium.
I don't think long and ulong should ever implicitly convert to floating
point types. Note that you can just do *1.0 or *1.0L if you want to
convert them.
Currently long implicitly converts even to float. This seems quite bad,
it loses 60% of its bits!!
Suppose we also banned implicit conversions int->float and uint->float
(since float only has 24 bits, these are lossy conversions, losing 25%
of the bits).
Now that we've disallowed lossy integral conversions, it really seems
that we should disallow these ones as well.
If that was all we did, it would also mean that things like short+short
wouldn't convert to float either, because C converts everything to int
whenever it gets an opportunity. But we could use range checking to
restore this (and to allow small longs to fit into doubles: allow
conversion to double if it's <= 53 bits, allow conversion to float if <=
24 bits).
