Treating the abusive unsigned syndrome

Derek Parnell derek at psych.ward
Thu Nov 27 14:55:12 PST 2008


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



More information about the Digitalmars-d mailing list