Derek Parnell wrote:
On Thu, 27 Nov 2008 16:23:12 -0600, Andrei Alexandrescu wrote:
Derek Parnell wrote:
On Tue, 25 Nov 2008 09:59:01 -0600, Andrei Alexandrescu wrote:
D pursues compatibility with C and C++ in the following manner: if a
code snippet compiles in both C and D or C++ and D, then it should have
the same semantics.
Interesting ... but I don't think that this should be the principle
employed. If code is 'naughty' in C/C++ then D should not also produce the
same results.
I would propose that a better principle to be used would be that the
compiler will not allow loss or distortion of information without the
coder/reader being made aware of it.
These two principle are not necessarily at odds with each other. The
idea of being compatible with C and C++ is simple: if I paste a C
function from somewhere into a D module, the function should either not
compile, or compile and run with the same result. I think that's quite
reasonable. So if the C code is behaving naughtily, D doesn't need to
also behave naughty. It should just not compile.
I think we are saying the same thing. If the C code compiles AND if it has
the potential to lose information then the D compiler should not compile it
*if* the coder has not given explicit permission to the compiler to do so.
Oh, sorry. Yes, absolutely!
In those cases where the target type is not explicitly coded, such as using
'auto' or as a temporary value in an expression, the compiler should assume
a signed type that is 'one step' larger than the 'unsigned' element in the
expression.
e.g.
auto x = int * uint; ==> 'x' is long.
I don't think this will fly with Walter.
And that there is our single point of failure.
If this causes code to be incompatible to C/C++, then it implies that the
C/C++ code was poor (i.e. potential information loss) in the first place
and deserves to be fixed up.
I don't quite think so. As long as the values are within range, the
multiplication is legit and efficient.
Of course. *If* the compiler can determine that the result will not lose
information when being used, then it is fine. However, that is not always
going to be the case.
Well here are two objective at odds with each other. One is the
systems-y level-y aspect: on 32-bit systems there is a 32-bit
multiplication operation that ought to be mapped to naturally by the
32-bit D primitive. I think there is some good reason to expect that.
Then there's also the argument you're making - and with which I agree -
that 32-bit multiplication really yields a 64-bit value, so the type of
the result should be long.
But if we really start down that path, infinite-precision integrals are
the only solution. Because when you multiply two longs, you'd need
something even longer and so on.
Anyhow, the ultimate reality is: we won't be able to satisfy every
objective we have. We'll need to strike a good compromise.
Andrei
