Deprecate `!a == b`

[Quirin Schroll]

On Wednesday, 14 August 2024 at 18:19:00 UTC, IchorDev wrote:
> On Wednesday, 14 August 2024 at 15:41:13 UTC, Dennis wrote:
>> On Wednesday, 14 August 2024 at 15:04:13 UTC, IchorDev wrote:
>>> I feel like integer promotion is a much more pressing issue 
>>> in that department. It’s one of the few things I wish we’d 
>>> just bin because it’s so atrocious.
>>
>> Oh, I thought the list represented things you _didn't_ want to 
>> see in the language. But your point is rather that D is not 
>> consistent about this kind of error prevention?
>
> What? No, I literally said that the only thing in that list 
> that I’d want in the language is the null cast thing, which is 
> impossible to do. I also stated separately that in an ideal 
> world we’d **completely remove** integer promotion. In the 
> list, the idea was that the compiler would force you to 
> manually write a cast whenever and wherever the compiler 
> decides to promote an integer, which would be an abomination:
> ```d
> short x = 1, y = 2;
> int z = x + y; //warning: integer promotion must be explicit
> int w = cast(int)x + cast(int)y;
> int ohNo = cast(int)x * cast(int)x + cast(int)y * cast(int)y + 
> z*z + w*w;
> ```

IMO, not an example. “Integer promotion” to me means not implicit 
conversions from smaller integer types to bigger ones (like 
`short` to `int`), but the fact that `typeof(x + y)` is `int`.

What I’d bin immediately is signed integer types converting to 
unsigned ones in any way (except for compile-time known 
happens-to-be-nonnegative values). Why can I add a `uint` and 
`short`? The intuitive answer would be: Because the result can 
fit in a `long` and we’re good – but in D, `typeof(uint(0) + 
short(-1))` is `uint`. It should require a cast: Either of the 
result or of the unsigned operand to a signed type.

>>> And personally I’ve been screwed over by arithmetic operator 
>>> precedence on many occasions.
>>
>> Same, which is why I often defensively parenthesize 
>> expressions with binary operators.
>
> I do that less and less. I think that learning the precedence 
> and omitting the parenthesis makes the code a lot easier to 
> sight-read. The tipping point for me is about 3 nested 
> parenthesis, after which they all start to blur together.

I can handle parentheses a lot better when they’re not adjacent. 
I sometimes wish for abbreviation constructs such as `static 
assert is(..)` and even `is typeof()` which just mean what they’d 
mean with the obvious parentheses added, so that instead of:
```d
static assert(is(typeof(a * (b + (c ? 0 : 1)))));
```
you could write
```d
static assert is typeof(a * (b + (c ? 0 : 1)));
```

I’d also love if `if`, `while` and `switch` allowed an arbitrary 
[`PrimaryExpression`](https://dlang.org/spec/grammar.html#PrimaryExpression) instead of requiring parentheses.