On 10/24/2017 09:59 AM, Arun Chandrasekaran wrote:
>>> On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:
>>> > The rule is that every expression has a type and 22/7 is int.
> I'm just questioning the reasoning behind why D does it this way and if
> it is for compatibility or if there is any other reasoning behind the
> decision.
I'm not a language designer so I can't be sure but I think it has the
same reasons that it has in C.
The alternative would not be fit for a system language because we
wouldn't know what types would be used for certain operations. And types
are related to performance because they may be operated on different
sets of CPU registers. In the case of floating point, a CPU need not
have floating registers at all. So, we don't want types slip from under
our grasp because the compiler decided to help the programmer. (One may
think that all common CPUs have FP processing units today but it may not
be the case in the future. For example, the not-yet-shipping Mill CPU
can be configured to have zero or more processing units of any kind.)
And we haven't talked about what type 14/7 should be. If we want that to
be int, then I think we're in bigger trouble. (I think a timing values
should be shorter than 22/7 and suddenly I get an int in my hand.)
And only after writing that last sentence I realize that perhaps you
meant this only for literals. If so, having same rules for literals vs.
variables is beneficial and very important.
There are known problems with C, C++, and D compilers' choosing finer
precision during compile time for floating point literals during macro
expansions. For example, calculations end up having different results on
different compilations.
Languages like Python 3+ can afford all of this because types or
performance don't play a strong role in that environment. ;)
Ali
