On Monday, 22 January 2024 at 01:14:06 UTC, Steven Schveighoffer wrote:
>On Sunday, 21 January 2024 at 16:05:40 UTC, Gavin Gray wrote:
>The following code:
ulong charlie = 11;
long johnstone = std.algorithm.comparison.max(0, -charlie);
writeln(format!"johnstone %s"(johnstone));
Results in (without any warning(s)):
johnstone -11
However you choose to look at it, this means -11 > 0 (regardless of all arguments concerning implicit conversions, 1's and 2's complements, being efficient, etc).
The language should not allow unary unsigned anything.
This is unlikely to get fixed, just due to the nature of D's philosophy when it comes to C compatibility.
There's a hope that OpenD may try to improve the current situation. A related discussion can be found here: https://github.com/orgs/opendlang/discussions/4
>It would also break a lot of existing code.
How did you estimate that it's a lot of existing code? As an experiment, I tried to patch Druntime and Phobos to avoid signed overflows roughly a year ago: https://github.com/ssvb/gcc/commits/gdc-ftrapv-phobos-20220209/
And there were not too many places in the code that actually needed any fixes. Additionally taking care of unsigned overflows would surely require more changes, but I doubt that they are going to be big. In most cases encountering an arithmetic overflow is unexpected and undesired, it's typically the symptom of a bug in the code. Some clever bit-tricks relying on two's complement wrap-around exist, but they are: 1) not very common 2) can be easily debugged if arithmetic overflows are trapped at runtime 3) can be easily patched up. The two's complement wraparound behavior mandated by the D language spec is a non-technical political decision, intended to make life easier for the DMD compiler developers, but ignoring the needs of the users.