On Friday, 29 October 2021 at 14:20:09 UTC, Ali Çehreli wrote:
> Unsigned!T abs(T)(const(T) x) if(isIntegral!T)
> {
>    static if(isSigned!T) if(x < 0) return cast(Unsigned!T)-x;
>    return x;
> }
>
> void main() {
>   int a = -5;
>   int b = -4;
>   writeln(a + abs(b)); // -5 + 4 == -1? (No!)
> }
>
> The program prints uint.max.

This should be no surprise. You need to know what the resulting type of int + uint should be. And it is ...... uint!  which is one of the stupit integer-promotion rules inherited from C. I just don't understand how "promoting" something by dropping some important information (the sign) and on the fly also destroying the absolute value can ever be a good choice. I always thought it should be the other way round.
The way it is is like "promoting" int + float to int (by discarding the fraction part and possibly too high exponents). And those two types are also of same size, so this is not an argument.
Promotion should always be in a direction where it at least sometimes can be correct.

On Sunday, 31 October 2021 at 05:04:33 UTC, Dom DiSc wrote:
> This should be no surprise. You need to know what the resulting type of int + uint should be. And it is ...... uint!  which is one of the stupit integer-promotion rules inherited from C.

In C++ it is undefined behaviour to take the absolute value of a value that has no positive representation. I assume the same is true for C? So you can write a compiler that detects it and fails.

You cannot do this in D as int is defined to represent an infinite set of numbers (mapped as a circle). So in D, you could say that the abs of the most negative value is a positive value that is represented as a negative due to circular wrapping.

If this happens in C then it is a bug. If it happens in D, then it is a defined feature of the language.

On Sunday, 31 October 2021 at 05:04:33 UTC, Dom DiSc wrote:
> On Friday, 29 October 2021 at 14:20:09 UTC, Ali Çehreli wrote:
>> Unsigned!T abs(T)(const(T) x) if(isIntegral!T)
>> {
>>    static if(isSigned!T) if(x < 0) return cast(Unsigned!T)-x;
>>    return x;
>> }
>>
>> void main() {
>>   int a = -5;
>>   int b = -4;
>>   writeln(a + abs(b)); // -5 + 4 == -1? (No!)
>> }
>>
>> The program prints uint.max.
>
> This should be no surprise. You need to know what the resulting type of int + uint should be. And it is ...... uint!  which is one of the stupit integer-promotion rules inherited from C.

Then let's change the example to:

   int b = -4;
   writeln(-abs(b));

What would one normally expect to be printed here? Should the unary minus operator also do some kind of implicit "unsigned -> signed" type change magic to accommodate this modified version of the abs function and make it behave in a non-surprising way?

On Sunday, 31 October 2021 at 10:12:49 UTC, Siarhei Siamashka wrote:
> On Sunday, 31 October 2021 at 05:04:33 UTC, Dom DiSc wrote:
>> On Friday, 29 October 2021 at 14:20:09 UTC, Ali Çehreli wrote:
>>> [...]
>>
>> This should be no surprise. You need to know what the resulting type of int + uint should be. And it is ...... uint!  which is one of the stupit integer-promotion rules inherited from C.
>
> Then let's change the example to:
>
>    int b = -4;
>    writeln(-abs(b));
>
> What would one normally expect to be printed here? Should the unary minus operator also do some kind of implicit "unsigned -> signed" type change magic to accommodate this modified version of the abs function and make it behave in a non-surprising way?

What I would like is for it to mirror math.

On 10/30/21 10:04 PM, Dom DiSc wrote:
> On Friday, 29 October 2021 at 14:20:09 UTC, Ali Çehreli wrote:
>> Unsigned!T abs(T)(const(T) x) if(isIntegral!T)
>> {
>>    static if(isSigned!T) if(x < 0) return cast(Unsigned!T)-x;
>>    return x;
>> }
>>
>> void main() {
>>   int a = -5;
>>   int b = -4;
>>   writeln(a + abs(b)); // -5 + 4 == -1? (No!)
>> }
>>
>> The program prints uint.max.
>
> This should be no surprise. You need to know what the resulting type of
> int + uint should be.

Yes, the programmer knew all that when they wrote that code when abs() behaved the way it behaves today.

The code is an example of why abs() cannot be changed today to what you propose. It would be a bad kind of breaking change: No compilation error, no run-time error (if unlucky), and a weird bug 42 months from today.

Ali