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. >> 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. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
