OT (partially): about promotion of integers

[foobar]

On Tuesday, 11 December 2012 at 16:35:39 UTC, Andrei Alexandrescu 
wrote:
> On 12/11/12 11:29 AM, eles wrote:
>>> There's a lot to be discussed on the issue. A few quick 
>>> thoughts:
>>>
>>> * 32-bit integers are a sweet spot for CPU architectures. 
>>> There's
>>> rarely a provision for 16- or 8-bit operations; the action is 
>>> at 32-
>>> or 64-bit.
>>
>> Speed can be still optimized by the compiler, behind the 
>> scenes. The
>> approach does not asks the compiler to promote everything to
>> widest-integral, but to do the job "as if". Currently, the 
>> choice of
>> int-C as the fastest-integral instead of widest-integral move 
>> the burden
>> from the compiler to the user.
>
> Agreed. But then that's one of them "sufficiently smart 
> compiler" arguments. 
> http://c2.com/cgi/wiki?SufficientlySmartCompiler
>
>>> * Then, although most 64-bit operations are as fast as 32-bit 
>>> ones,
>>> transporting operands takes twice as much internal bus real 
>>> estate and
>>> sometimes twice as much core real estate (i.e. there are 
>>> units that do
>>> either two 32-bit ops or one 64-bit op).
>>>
>>> * The whole reserving a bit and halving the range means extra 
>>> costs of
>>> operating with a basic type.
>>
>> Yes, there is a cost. But, as always, there is a balance 
>> between
>> advantages and drawbacks. What is favourable? Simplicity of 
>> promotion or
>> a supplimentary bit?
>
> A direct and natural mapping between language constructs and 
> machine execution is very highly appreciated in the market D is 
> in. I don't see that changing in the foreseeable future.
>
>> Besides, at the end of the day, a half-approach would be to 
>> have a
>> widest-signed-integral and a widest-unsigned-integral type and 
>> only play
>> with those two.
>
> D has terrific abstraction capabilities. Lave primitive types 
> alone and define a UDT that implements your desired behavior. 
> You can always implement safe on top of fast but not the other 
> way around.
>
>
> Andrei

All of the above relies on the assumption that the safety problem 
is due to the memory layout. There are many other programming 
languages that solve this by using a different point of view - 
the problem lies in the implicit casts and not the memory layout. 
In other words, the culprit is code such as:
uint a = -1;
which compiles under C's implicit coercion rules but _really 
shouldn't_.
The semantically correct way would be something like:
uint a = 0xFFFF_FFFF;
but C/C++ programmers tend to think the "-1" trick is less 
verbose and "better".
Another way is to explicitly state the programmer's intention:
uint a = reinterpret!uint(-1); // no run-time penalty should occur

D decided to follow C's coercion rules which I think is a design 
mistake but one that cannot be easily changed.

Perhaps as Andrei suggested, a solution would be to use a higher 
level "Integer" type defined in a library that enforces better 
semantics.