Sky Rose (Feb 21 2025 at 03:08): Sky Rose (Feb 21 2025 at 03:08):This came up when discussing match syntax, but I'm splitting it into a new thread cuz this problem already exists in functions.
Sam Mohr said:
match a { | Blue | Red | Green | Yellow }
If you can use any pattern in a function, and you use the pattern Blue | Red, then your function definition looks like | Pattern1 | Pattern2 | Result which isn't good.
In practice it's unlikely to come up for function defintions because | Tag1 | Tag2 | is not a very useful way to define a function, but if we're allowing any arbitrary pattern in a function definition, it should still be allowed.
It would be much more likely to come up if we reused the syntax for patterns in matches.
Will this be a problem, and how should it be fixed?
Sky Rose (Feb 21 2025 at 03:10):Option 1: Use or instead of | #ideas > ✔ `or` instead of `|` in `when` branches , but that idea was rejected already
Sky Rose (Feb 21 2025 at 03:12):What if we used + for patterns? | Red + Blue |.
This matches the academic idea of sum types, seems simple, and is otherwise unused in patterns, but would be unfamiliar to most people.
Notification Bot (Feb 21 2025 at 03:27):This topic was moved here from #ideas > | ambiguity in function defintion by Sky Rose.
Richard Feldman (Feb 21 2025 at 03:30):I prefer or because:
or keyword Sam Mohr (Feb 21 2025 at 03:30):get_user_email = |Admin({ email, .. }) + Guest(email)| email
get_user_email = |Admin({ email, .. }) or Guest(email)| email
I think or implies "one or the other"
Sam Mohr (Feb 21 2025 at 03:31):But + implies "both"
Sam Mohr (Feb 21 2025 at 03:31):So I also lean or
Sky Rose (Feb 21 2025 at 03:38)::thumbs_up: I still dislike a couple things about or (from the other thread), but it is a totally safe choice.
Joshua Warner (Feb 21 2025 at 04:35):I actually kinda like zig's ,, especially how it interacts with the formatter. Adding a trailing comma always formats multiline, and visa versa. Super easy and controllable.
Anthony Bullard (Feb 21 2025 at 11:27):I want to register my support for Redacted after thinking about it in the context of Roc's pattern matching capabilities - which are MUCH richer than ZIg,
Eli Dowling (Feb 21 2025 at 11:28):Might be a little confusing with tuples and lists
Anthony Bullard (Feb 21 2025 at 11:28):That's what I was just about to write
Anthony Bullard (Feb 21 2025 at 11:28):The problem is that alternatives internal to a collection would have to be surrounded by ()
Anthony Bullard (Feb 21 2025 at 11:30):But to flesh out the design space, the only other symbol that makes sense to use here is ^
Anthony Bullard (Feb 21 2025 at 11:30):get_user_email = |Admin({ email, .. }) ^ Guest(email)| email
I guess / also has the connotation of "either or"
Anthony Bullard (Feb 21 2025 at 11:31):get_user_email = |Admin({ email, .. }) / Guest(email)| email
match e {
|Admin({ email, .. }) ^ Guest(email) if email.ends_with("gmail.com")| email
|Admin({ email, .. }) / Guest(email) if email.ends_with("gmail.com")| email
|Admin({ email, .. }) or Guest(email) if email.ends_with("gmail.com")| email
Admin({ email, .. }) ^ Guest(email) if email.ends_with("gmail.com") -> email
Admin({ email, .. }) / Guest(email) if email.ends_with("gmail.com") -> email
Admin({ email, .. }) | Guest(email) if email.ends_with("gmail.com") -> email
Admin({ email, .. }) or Guest(email) if email.ends_with("gmail.com") -> email
Admin({ email, .. }) ^ Guest(email) if email.ends_with("gmail.com") => email
Admin({ email, .. }) / Guest(email) if email.ends_with("gmail.com") => email
Admin({ email, .. }) | Guest(email) if email.ends_with("gmail.com") => email
Admin({ email, .. }) or Guest(email) if email.ends_with("gmail.com") => email
Admin({ email, .. }) ^ Guest(email) if email.ends_with("gmail.com") { email }
Admin({ email, .. }) / Guest(email) if email.ends_with("gmail.com") { email }
Admin({ email, .. }) | Guest(email) if email.ends_with("gmail.com") { email }
Admin({ email, .. }) or Guest(email) if email.ends_with("gmail.com") { email }
}
Here's I think the entire design space that has been talked about
Kiryl Dziamura (Feb 21 2025 at 12:29):Btw, wanted to note that it’s kinda inconsistent that tag unions are declared as [A, B, C] but pattern matched as A | B | C. Is it reasonable to align them somehow? I feel absolutely comfortable with the status quo, just want to give another perspective to the problem in the thread
Sam Mohr (Feb 21 2025 at 12:52):It feels like making the types use pipes would be a great alignment, but it's don't know how to represent type extensions there
Brendan Hansknecht (Feb 21 2025 at 17:14):I definitely don't think we should use +. People expect plus to do something. And in some cases it might (especially with operator overloading in the future)
Red + Blue is that two patterns or is that a custom type addition that will result in Purple?
Brendan Hansknecht (Feb 21 2025 at 17:15):I like how terse and simple | is. I think non-text is easier to format nicely than chains of text like would exist with or
Brendan Hansknecht (Feb 21 2025 at 17:16):But I think I would be fine with any of |, or, and ,
Last updated: Jun 16 2026 at 16:19 UTC