On 2/2/2022 2:14 PM, Dukc wrote:
> We probably should not even warn on integer promotion. Code that would explicitly cast on every place where that is done would be incredibly ugly.

It also *causes* bugs. When code gets refactored, and the types change, those forced casts may not be doing what is desired, and can do things like unexpectedly truncating integer values.

One of the (largely hidden because it works so well) advances D has over C is Value Range Propagation, where automatic conversions of integers to smaller integers is only done if no bits are lost.

On Wednesday, 2 February 2022 at 23:27:05 UTC, Walter Bright wrote:
> One of the (largely hidden because it works so well) advances D has over C is Value Range Propagation, where automatic conversions of integers to smaller integers is only done if no bits are lost.

D's behavior is worse than C's in actual use. This is a source of constant annoyance when doing anything with the byte and short types.

The value range propagation only works inside single expressions and is too conservative to help much in real code.

On 2/2/2022 3:37 PM, Adam Ruppe wrote:
> D's behavior is worse than C's in actual use.

How?


> The value range propagation only works inside single expressions and is too conservative to help much in real code.

I find it works well. For example,

    int i;
    byte b = i & 0xFF;

passes without complaint with VRP. As does:

    ubyte a, b, c;
    a = b | c;

On 2/2/2022 6:25 PM, Siarhei Siamashka wrote:
> On Thursday, 3 February 2022 at 01:05:15 UTC, Walter Bright wrote:
>> On 2/2/2022 3:37 PM, Adam Ruppe wrote:
>>> The value range propagation only works inside single expressions and is too conservative to help much in real code.
>>
>> I find it works well. For example,
>>
>>     int i;
>>     byte b = i & 0xFF;
>>
>> passes without complaint with VRP.
> 
> No, it's doesn't pass: `Error: cannot implicitly convert expression i & 255 of type int to byte`.

My mistake. b should have been declared as ubyte.

> 
>> As does:
>>
>>     ubyte a, b, c;
>>     a = b | c;
> 
> But `a = b + c` is rejected by the compiler.

That's because `b + c` may create a value that does not fit in a ubyte.

> Maybe I'm expecting modular wrap-around arithmetic here? Or maybe I know the possible range of `b` and `c` variables and I'm sure that no overflows are possible? But the compiler requires an explicit cast. Why is it getting in the way?

Because C bugs where there are hidden truncations to bytes are a problem.


> Also if the type is changed to `uint` in the same example, then the compiler is suddenly okay with that and doesn't demand casting to `ulong`. This is inconsistent.

It follows the C integral promotion rules. This is for consistent arithmetic behavior with C.

 You will probably say that it's because of integer promotion and
> 32-bit size is a special snowflake. But if the intention is to catch bugs at the compilation stage, then adding two ubytes together and adding two uints together isn't very different (both of these operations can potentially overflow). What's the reason to be anal about ubytes?

We do the best we can. There really is no solution that doesn't have its own issues.

> The other modern programming languages can catch arithmetic overflows at runtime. And allow to opt out of these checks in performance critical parts of the code.

They just have other problems. VRP makes many implicit conversions to bytes safely possible.