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

    23 files     854 suites   6h 29m 38s ⏱️
10 814 tests 10 263 ✅ 551 💤 0 ❌
21 247 runs  20 277 ✅ 970 💤 0 ❌

Results for commit 31d81e6.

♻️ 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.

[richcarl]

Fixed , instead of ; in megaco that failed the type check.

[richcarl]

The windows build died for some reason: /mnt/d/a/_temp/87953a19-9c2f-4c2d-bffc-af974820c086: line 1: 284 Segmentation fault apt install -y g++-mingw-w64 gcc-mingw-w64 make autoconf unzip.

[garazdawi]

The windows build died for some reason: /mnt/d/a/_temp/87953a19-9c2f-4c2d-bffc-af974820c086: line 1: 284 Segmentation fault apt install -y g++-mingw-w64 gcc-mingw-w64 make autoconf unzip.

I re-triggered the windows run and now it seems to have passed.