Deprecate `!a == b` (page 4)

On Wednesday, 14 August 2024 at 14:36:50 UTC, Dennis wrote:

Whether !a == b is such a case depends. You apparently have seen intentional use, so it makes sense you judge it as not worth adding an error for. I'm actually curious, can you link to real code using that pattern intentionally?

I can’t link something, but I have definitely written something like that at some point to implement a XOR for bools. There are loads of situations where you need to test that two bools are equal or unequal and !a == b is a way to say a != b. It’s not a good way, granted, but I can definitely see why beginner me would have written that: a != b could compare anything, !a == b compares bools. What I’m saying is not that it’s good code, but not wildly unrealistic code either. The language keeping someone from writing that is a good thing. It’s in the same ballpark as x => {} not being allowed.

August 28

Re: Deprecate `!a == b`

Posted by Quirin Schroll
in reply to IchorDev

Permalink

Quirin Schroll

Posted in reply to IchorDev

Permalink

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:

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:

static assert(is(typeof(a * (b + (c ? 0 : 1)))));

you could write

static assert is typeof(a * (b + (c ? 0 : 1)));

I’d also love if if, while and switch allowed an arbitrary PrimaryExpression instead of requiring parentheses.

Forums