On Tuesday, 13 August 2024 at 21:02:28 UTC, Nick Treleaven wrote:

My point being that it’s a weird mistake to make, and one I’ve never seen. Have you ever seen it before?

I learned programming to learn programming, not to learn mathematics. A lot of concepts from mathematics are completely incompatible with programming because we work with numbers that have to be physically stored. You can’t store irrational numbers, you can’t even store recursive fractions without a special encoding system, and even then there’ll still be a fraction that’s too long to store in the universe.

Well there’s still situations like ternary enums to account for.

On Tuesday, 13 August 2024 at 21:13:17 UTC, Dennis wrote:

bool f(int x)
{
    x == 3;
}

Wow you have some… strange problems.

When you write the wrong thing, you get the wrong result. The language doesn’t pull any punches when it comes to much more complex things, so why be pedantic with something so elementary? If you want something like this to have an anti-goof mechanism, let’s just add such a mechanism for all of the other situations that might trip up a beginner:

• mutability attributes are transitive —> always require parenthesis after mutability attributes
• integral to floating point conversion can occur implicitly —> require a cast
• operator precedence is arbitrary —> require parenthesis around every operator
• cast doesn’t always do the same thing —> require a cast keyword after the type to make sure the programmer knows what type of cast it is (e.g. cast(long, signExtend)myInt)
• dereferencing null values —> require a cast to typeof(null) ;)
• contracts shouldn’t have side effects —> treat contract code as pure
• integer promotion is stupid —> require a cast

Other languages will always have things that work in contradictory ways, should we really shape the language around that?
Also if we added last-expression return then it would generally be convenient, instead of inconvenient like the proposed feature. Not that I’m particularly for or against last-expression return, it is what it Is.

Exceptions terminate for loops, numbers are immutable class instances, +, and now this too? This is no python, it’s more akin to Jörmungandr!

On Wednesday, 14 August 2024 at 13:26:44 UTC, IchorDev wrote:

If you've never made such silly programming mistakes, enjoy it while it lasts!

Interesting list. Some of them have been seriously suggested for D or implemented in other languages. Specifically, D's integer promotion rules get criticized a lot, and some languages are a lot stricter about it.

I do agree with you generally: just because a combination of features is commonly used mistakenly, doesn't mean a special case should be added disallowing the combination.

However, there are cases where the ratio of erroneous usage / intentional usage is so large, that a compiler error will in practice reduce the total amount of 'programmer rage' so to speak.

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?

All I'm saying is that it's possible for polyglot programmer's to make mixups, in response to you saying you couldn't imagine how someone could make a mistake like !a == b.

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

Thanks. I’m surprised my knackered brain still manages not to make such mistakes if they’re so common.

Yes and I’m sure people have suggested requiring parenthesis after mutability attributes. The only one of those things I seriously want is requiring an explicit cast before dereferencing null; but it would require the compiler to literally be magical since it needs to be a compile-time feature obviously, but it depends on a runtime value.

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. And personally I’ve been screwed over by arithmetic operator precedence on many occasions.

I don’t think I said that? I might’ve written something like that a long time ago in another language. I don’t usually read other people’s code for fun, but it’s the kind of thing I can see myself writing, although probably as x == !y because it looks nicer. Also C code often uses int for booleans, so code that interfaces with C could trigger this mechanism even if we add an exception for bool.

On Wednesday, 14 August 2024 at 15:04:13 UTC, IchorDev wrote:

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?

Same, which is why I often defensively parenthesize expressions with binary operators.

My bad, I thought your !myInt == myBool example was based on something you wrote in the past.

On Wednesday, 14 August 2024 at 15:41:13 UTC, Dennis wrote:

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;

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.

On Wednesday, 14 August 2024 at 14:48:42 UTC, user1234 wrote:

Sounds like a better idea to do that. I’m not a fan of having more ‘it’s unintuitive therefore we’ll force the code to be unreadable’ features like bitwise operators requiring parenthesisation.