Richard Feldman (Feb 02 2025 at 22:35): Richard Feldman (Feb 02 2025 at 22:35):what if instead of having | separate different alternatives in pattern matches, we used or?
e.g.
when result is
Ok(str) -> str
Err(FileErr or BadUtf8) -> "err"
seems more self-descriptive
Sam Mohr (Feb 02 2025 at 22:46):It is more self-descriptive, but the value of symbols here are that they're more visually sparse and distinct than words. I think the pipe is better at chunking patterns for the eyes
Sam Mohr (Feb 02 2025 at 22:47):Though or would make parsing simpler/more performant, the parser is probably so cheap compared to the rest of the compiler that I don't think a minor readability loss is worth it
Sam Mohr (Feb 02 2025 at 22:47):If everyone else thinks it's more readable, then sure. That's separate, though
Richard Feldman (Feb 02 2025 at 22:48):yeah that's why I didn't bring up the parsing considerations here - I'm curious what others think just in terms of how the code reads!
Anthony Bullard (Feb 02 2025 at 22:49):Really depends on the syntax highlighting
Anthony Bullard (Feb 02 2025 at 22:49):If it’s good, I think it reads fine
Richard Feldman (Feb 02 2025 at 22:49):let's assume it's good :big_smile:
Anthony Bullard (Feb 02 2025 at 22:50):Though this style you’ve put here is unusual
Anthony Bullard (Feb 02 2025 at 22:50):An or pattern in the interior of another pattern that is
Richard Feldman (Feb 02 2025 at 22:50):yeah I don't think we actually support it yet :sweat_smile:
Anthony Bullard (Feb 02 2025 at 22:51):I’d expect to see:
when result is
Ok(str) -> str
Err(FileErr) or Err(BadUtf8) -> "err"
Are you including that in this proposal?
Luke Boswell (Feb 02 2025 at 22:52):Maybe there is a benefit to having a different syntax for "Types" | as opposed to "values" or.
Personally I think the or is objectively clearer and more expressive of intent.
Anthony Bullard (Feb 02 2025 at 22:52):IE, making alternatives inside of a pattern legal?
Sam Mohr (Feb 02 2025 at 22:53):I think we should absolutely allow that
Sam Mohr (Feb 02 2025 at 22:53):It's very useful at removing clutter from complex patterns
Anthony Bullard (Feb 02 2025 at 22:53):I don’t know if I’ve seen that in a language
Anthony Bullard (Feb 02 2025 at 22:53):But seems useful
Luke Boswell (Feb 02 2025 at 22:54):when tag_union is
Apples -> "delicious"
Bananas | Oranges | _ -> "gross"
when tag_union is
Apples -> "delicious"
Bananas or Oranges or _ -> "gross"
Makes me want to suggest:
when tag_union is
Apples then "delicious"
Bananas or Oranges or _ then "gross"
Rust does it
Richard Feldman (Feb 02 2025 at 22:56):wait we all know that Roc already supports | like this today, right?
Richard Feldman (Feb 02 2025 at 22:57):I'm just talking about renaming it to or
Anthony Bullard (Feb 02 2025 at 22:57):It supports it inside of a destructure?
Sam Mohr (Feb 02 2025 at 22:57):I'm talking with Anthony about | within a pattern
Sam Mohr (Feb 02 2025 at 22:57):Like Rust does
Anthony Bullard (Feb 02 2025 at 23:00):I don’t think I’ve ever seen that in Rust either, but I trust Sam on that
Sam Mohr (Feb 02 2025 at 23:02):I think it's fine with syntax highlighting
Anthony Bullard (Feb 02 2025 at 23:04):You’d definitely want different formatting I think for multiline
Anthony Bullard (Feb 02 2025 at 23:05):Trailing or instead of leading with |
Sam Mohr (Feb 02 2025 at 23:06):I still have no good heuristic for when we use symbols instead of keywords. It feels like we do it for
gte Anthony Bullard (Feb 02 2025 at 23:06):when tag_union is
Apples -> "delicious"
Bananas or
Oranges or
_ -> "gross"
I really don't like that you need to read the end of a line to scan the code
Sam Mohr (Feb 02 2025 at 23:06):Not a fan of or if that's required
Anthony Bullard (Feb 02 2025 at 23:06):Wow, really?
Sam Mohr (Feb 02 2025 at 23:07):Not perfect either, but we can use two spaces before the or to keep it at the start of the line
Anthony Bullard (Feb 02 2025 at 23:07):This reads better to you?
when tag_union is
Apples -> "delicious"
Bananas
or Oranges
or _ -> "gross"
I've been trying to push for scanability
Anthony Bullard (Feb 02 2025 at 23:08):That’s what the trailing or was for
Anthony Bullard (Feb 02 2025 at 23:08):I figured with syntax highlighting it’s distinct
Sam Mohr (Feb 02 2025 at 23:08):And I think we either need an obvious symbol like | or some indent
Sam Mohr (Feb 02 2025 at 23:08):when tag_union is
Apples -> "delicious"
Bananas
or Oranges
or _ -> "gross"
I want to really narrowly scope what I'm talking about in this thread
Richard Feldman (Feb 02 2025 at 23:09):it's just find/replace | with or, that's it :big_smile:
Richard Feldman (Feb 02 2025 at 23:09):everything else is out of scope for this idea
Sam Mohr (Feb 02 2025 at 23:09):I agree
Anthony Bullard (Feb 02 2025 at 23:09):Sure
Sam Mohr (Feb 02 2025 at 23:09):But how we format code with or affects my decision
Anthony Bullard (Feb 02 2025 at 23:09):Then this is what you get on multiline:
when tag_union is
Apples -> "delicious"
Bananas
or Oranges
or _ -> "gross"
And I think that influences opinions
Sam Mohr (Feb 02 2025 at 23:10):Because as Anthony is pointing out, the readability is worse for multiline
Sam Mohr (Feb 02 2025 at 23:10):If we couldn't change formatting, I'd say it's not worth it
Sam Mohr (Feb 02 2025 at 23:10):Even if we could, I'm not sure
Anthony Bullard (Feb 02 2025 at 23:11):Without the real syntax highlighting it might be hard to gauge fairly
Anthony Bullard (Feb 02 2025 at 23:11):In Ruby or is an operator not a keyword
Anthony Bullard (Feb 02 2025 at 23:12):If when, is, and or were highlighted the same it might strike you differently
Richard Feldman (Feb 03 2025 at 00:09):what does the ideal or formatting look like next to the ideal | formatting?
Richard Feldman (Feb 03 2025 at 00:09):(I'm on mobile, can't write them out easily :sweat_smile:)
Luke Boswell (Feb 03 2025 at 00:10):Well I thought this #ideas > `or` instead of `|` in `when` branches @ 💬 for single line
Luke Boswell (Feb 03 2025 at 00:11):Or this for multi-line
when tag_union is
Apples ->
"delicious"
Bananas
| Oranges
| _ ->
"gross"
when tag_union is
Apples _ _ _ _ _ _ _ ->
"delicious"
Bananas _ _ _ _ _ _ _
or Oranges _ _ _ _ _ _ _
or _ ->
"gross"
edit : updated based on Sam's comment below
Sam Mohr (Feb 03 2025 at 00:12):I think the newlines are doing work here
Sam Mohr (Feb 03 2025 at 00:13):If the patterns are longer for the or example, it's a bigger problem that or is at the end
Luke Boswell (Feb 03 2025 at 00:14):Updated it to have leading or to help with longer patterns
Anthony Bullard (Feb 03 2025 at 00:15):To my eyes, the trailing or still reads better
Anthony Bullard (Feb 03 2025 at 00:15):But I am but one man
Luke Boswell (Feb 03 2025 at 00:17):Anthony Bullard said:
To my eyes, the trailing or still reads better
Here you go
when tag_union is
Apples _ _ _ _ _ _ _ ->
"delicious"
Bananas _ _ _ _ _ _ _ or
Oranges _ _ _ _ _ _ _ or
_ ->
"gross"
I like the trailing or. I'm definitely more familiar with the |.
I do think the or's are clearer for someone who isn't already steeped in programming language syntax. It almost reads like a sentence.
Richard Feldman (Feb 03 2025 at 00:20):it feels to me like the tradeoffs between or and | are similar to the tradeoffs between or and || in terms of readability
Anthony Bullard (Feb 03 2025 at 00:25):Luke Boswell said:
I like the trailing
or. I'm definitely more familiar with the|.I do think the
or's are clearer for someone who isn't already steeped in programming language syntax. It almost reads like a sentence.
This is why I have-jokingly suggested that if this moved forward, replacing -> with then makes sense as well. But there are lots of opinions on words over symbols here
Richard Feldman (Feb 03 2025 at 00:40):I personally like then over -> in the abstract
Richard Feldman (Feb 03 2025 at 00:40):it wasn't well-received last time but I also don't think we really seriously considered it haha
Richard Feldman (Feb 03 2025 at 00:41):(the thing I like about it in the abstract is just that -> now means "pure function" and when branches are purity-agnostic)
Anthony Bullard (Feb 03 2025 at 00:44):Yep
Luke Boswell (Feb 03 2025 at 00:47):I like then also... in general I think the keywords are clearer.
Anthony Bullard (Feb 03 2025 at 00:47):Especially with control flow
Richard Feldman (Feb 03 2025 at 00:52):if anyone wants to start a thread about it, feel free!
Brendan Hansknecht (Feb 03 2025 at 01:38):I really dislike or in when branches, just feels verbose and overly wordy....but I am used to rust which just uses a |. I like or for booleans. I'm not a fan of it for patterns.
Brendan Hansknecht (Feb 03 2025 at 01:38):But I'm sure I would eventually get used to whatever
Isaac Van Doren (Feb 03 2025 at 02:19):Yeah I also much prefer pipe here
Ben (Feb 03 2025 at 04:11):I like or. I feel like it unifies the syntax with ifs. It seems inconsistent to have different operators when you're "matching" on boolean expressions vs matching on types. It would be nice to be able to read ifs and whens in the same way and that could be another argument for adding then too
Brendan Hansknecht (Feb 03 2025 at 04:12):I mean they functionally do different things
Brendan Hansknecht (Feb 03 2025 at 04:13):One is selecting from many possible patterns. The other passing on the first true value found with short circuiting.
Ben (Feb 03 2025 at 04:17):Just to push a bit - if can be thought of as matching when you're interested in one possible pattern. when pattern matching can short circuit as well.
Brendan Hansknecht (Feb 03 2025 at 04:18):There is nothing to short circuit cause there are no evaluated expressions
Ben (Feb 03 2025 at 04:19):Brendan Hansknecht said:
There is nothing to short circuit cause there are no evaluated expressions
You're right, I take that back
Brendan Hansknecht (Feb 03 2025 at 04:19):But yeah, I do agree that they still roughly are the same idea, so it may feel nice for consistency.
Sam Mohr (Feb 03 2025 at 06:27):when tag_union is
Apples _ _ _ _ _ _ _ -> "delicious"
Bananas _ _ _ _ _ _ _ or
Oranges _ _ _ _ _ _ _ or
_ ->
"gross"
This is what I think will get hairy. We can force the formatter to move single line branches to be multiline if any patterns are multiline? Not great, but I think it'd be better than the above
Sky Rose (Feb 03 2025 at 17:27):Or is very familiar in expressions, but seeing it in a pattern match makes me feel like it's doing some sort of calculation or transformation of the types, but it's really more like control flow here. Like, Err(FileErr or BadUtf8) -> makes me think you're creating some new type/value/concept FileErr or BadUtf8, and it makes me want to do something like
pattern myPattern = FileErr or BadUtf8
...
Err(myPattern) ->
By contrast | feels more like it's part of the control flow and the syntax of when, just like , is part of the syntax of lists, and I don't have the same urge to see it as a calculation or pull it into a variable.
Richard Feldman (Feb 03 2025 at 21:49):seems like there isn't enough interest to justify changing, so let's keep it as |
Notification Bot (Feb 03 2025 at 21:53):Sky Rose has marked this topic as resolved.
Last updated: Jun 16 2026 at 16:19 UTC