Is it time for D 3.0?

[Steven Schveighoffer]

On 3/30/20 1:54 AM, rikki cattermole wrote:
> On 30/03/2020 6:51 PM, Denis Feklushkin wrote:
>> On Sunday, 29 March 2020 at 13:34:44 UTC, Steven Schveighoffer wrote:
>>> On 3/28/20 1:09 PM, Denis Feklushkin wrote:
>>
>>>> int -> int32
>>>> ulong -> uint64
>>>> float -> float32
>>>> double -> float64
>>>> byte -> octet
>>>
>>> I would say no, for 2 reasons. One, this is basically renaming 
>>> without benefit.
>>
>> My second proposal is remove auto casting to int while calculations:
>> int8 * int8 == int16 (not int32)
>>
>> Sometimes it causes unncessary casts. Intuitively it seems that it is 
>> uneconomical and possibly spoils superscalarity.
>>
>> Perhaps this from those ancient times when compatibility D with C was 
>> declared at source level? (Or am I confusing and there was no such 
>> period?)
> 
> C integer promotion is a feature, it is not going anywhere.

First, it's only a feature in that it means C code compiled as D will do 
the same thing as C (as long as it compiles). In other words, it's the C 
compatibility that's a feature, not that C integer promotion is the most 
desirable mechanism.

Second, it doesn't take long to break down:

auto z = x * y + 1000; // z must be int, no matter what type and y are.

The unnecessary casts are not terrible in any case, because at least you 
are aware of the odd truncation effect, I would say there's very little 
utility in the truncation effect.

A better option is to use more sane checked integer types if you want 
certain behavior.

-Steve