Make the compiler report 'and'/'or' operators as obsolete

[richcarl]

The strict 'and'/'or' operators are mostly useless, confusing for newcomers, rarely used in practice, and when used they can always be replaced with andalso/orelse. I think they should be obsoleted and subsequently dropped from the language.

[github-actions]

CT Test Results

    22 files     851 suites   6h 28m 20s ⏱️
10 725 tests 10 157 ✅ 541 💤 27 ❌
20 896 runs  20 026 ✅ 843 💤 27 ❌

For more details on these failures, see this check.

Results for commit af25af7.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[essen]

Should and and or be made to work the same as andalso and orelse in the future (after deprecation, removal, reintroduction, any other necessary steps, perhaps over a span of 5-10 years) so that we can shorten a bit our function clauses?

[richcarl]

Should and and or be made to work the same as andalso and orelse in the future (after deprecation, removal, reintroduction, any other necessary steps, perhaps over a span of 5-10 years) so that we can shorten a bit our function clauses?

Nah, I thought I'd try to introduce && and || instead.

Honestly I'm not sure. I think there's a bit of pedagogical value and visibility in the andalso/orelse keywords. (These names go back to Standard ML, if anyone wonders.) As I was replacing the occurrences of and/or in the code, I saw that a tiny 'or' or 'and' was easy to miss, but 'orelse' and 'andalso' stood out much better. So it might not even be worth doing, even if it saves horizontal space. We can submit a followup EEP in 2030 and see what people think then. 😜

Btw, replacing existing uses showed mainly two categories: 1) valid ways of writing more complex guards or other nested logical expressions (not all that common, in comparison to the total size of the codebase), and 2) as a personal style thing, where you could just as well have used comma and semicolon in a guard instead (only found in a few isolated modules) , possibly due to a lack of understanding of guard syntax. Also, a some of these occurrences probably go back to before semicolon was added to guards.

[essen]

I saw that a tiny 'or' or 'and' was easy to miss, but 'orelse' and 'andalso' stood out much better.

Indeed. I just tried finding them in RabbitMQ to fix them and it is clearly non-obvious. The other two have this advantage.

[richcarl]

@essen I did however come up with another use for 'or' (doesn't strictly require removing the original). Here's a very small proof of concept: master...richcarl:otp:or-patterns - e.g. case X of {a, Y} or {b, Y} or {c, Y} -> {yes, Y}; _ -> no end.

[essen]

case X of {a, Y} or {b, Y} or {c, Y} -> {yes, Y}; _ -> no end.

That would definitely remove a frequent pain point with regard to case clauses! 👍

[richcarl]

That would definitely remove a frequent pain point with regard to case clauses! 👍

Yes. It might be technically possible to use ; as separator, but I'm afraid it would get too unreadable. For example, foo({a, Y}; {b, Y}, {c, Y}) when Y >= $0, Y =< $9; Y =:= $@ -> {yes, Y}; _ -> no end. has the problem that ; binds tighter than , in the patterns, but the other way around in the guard. foo({a, Y} or {b, Y}, {c, Y}) when Y >= $0, Y =< $9; Y =:= $@ -> {yes, Y}; _ -> no end. is easier to read.

[bjorng]

Personally, I think that , and ; should be used if possible. I know that everyone does not agree with that.

As a compromise, if a guard only uses and, replace all and operators with commas. I think that is reasonable because , has been there since the beginning.

I strongly suggest that you remove the unnecessary parentheses on either side of andalso/orelse; not having to add those parentheses is one of the advantages over the older operators.

[richcarl]

Updated like @bjorng suggested. Definitely yields nicer code, but a bit harder to review.