Treating the abusive unsigned syndrome

[Andrei Alexandrescu]

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