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.
