[DRAFT] RFC: or patterns

This is a draft version of an RFC for you to review, before a formal proposal is made for consideration.

I’d particularly appreciate line comments in the PR for typos, better phrasing, or any omissions I might have made of alternatives, important details, as well as any additional motivation you might have etc.

9 Likes

Sounds nice, but we should avoid turning Rust into the world's finest functional programming language at all costs.

The operator | has low precedence such that i @ p | q means (i @ p) | q .

The Rust @ operator is so underpowered (to keep memory safety) that in practice I am not using it much. Most times I would find it useful in Haskell, I can't use it in Rust. I think that interaction between @ and | is a bit tricky because @ is not used much so a programmer could forget its precedence. So I suggest careful design of this part of your proposal.

2 Likes

Since i @ p | q will parse as (i @ p) | q, it’ll produce a compiler error since it doesn’t bind the same name i in both patterns; with a bit of extra error-reporting logic, we could have the resulting error include the suggestion to write i @ (p | q).

3 Likes

You use the word "we" to refer to two distinct sets of people. On the one hand, you're using it to refer to the author(s) and audience of the RFC. On the other, you're using to refer to only the authors. I'd choose one group and stick with it. I'd avoid using the word "we" to discuss beliefs without listing who "we" are, to avoid an impression of equivocation.

Consider lines 35-38:

We can see that this is clearly shorter and that the amount of extra work we have to do scales linearly with the number of inner variants we mention.

"We" refers to the audience (who is seeing), then to the author (who is mentioning). Instead:

This is clearly shorter, and the work scales linearly with the number of inner variants mentioned.

Also consider lines 42-45:

However, as we know, code is read more than it is written. So are we trading readability for increased ergonomics? We believe this is not the case. Instead, this RFC aims to improve the readability of code by reducing the amount of redundant information that needs to be scanned.

Here "we" refers to every user of rust (who may be trading), then to the authors (who are believing). Instead:

As we know, code is read more than it is written. So are we trading readability for increased ergonomics? No. This RFC claims that reducing the amount of redundant information that needs to be scanned improves the readability of code.

Both of the above examples say the same thing, but they don't attempt to associate the reader with the claims.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.