C++ Logo

std-discussion

Advanced search

Re: Ambiguity in P3476R0: To support multiple value pattern matching or not? If so, how?

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Wed, 6 Nov 2024 15:00:36 -0600
On Fri, Oct 18, 2024, 6:43 AM vspefs via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> I was reading P3476R0, the latest slides on P2688 (Pattern Matching:
> `match` Expression), and found specific content confusing.
>
> Question 1. To be or not to be
>
> The slide at page 6 shows the `{a, b} match ...` syntax for multiple
> values matching, and declares the removal of the design with a "workaround"
> of matching a single `std::tuple`, structured binding it to perform
> detailed matching in the `pattern`.
>
> Far as I see, both ways work well.
>
> Then the slides at page 35 & 36 presents more information about why the
> `{a, b} match ...` syntax got abandoned, and the practicability of adopting
> `(a, b) match ...` syntax as a drop-in replacement.
>
> So, are we going to use the `(a, b) match ...` replacement, or stick to
> the `std::tuple`/structured binding workaround? Because it affects only the
> `expr` before `match`, and I don't see big differences between them, I
> really don't know which one has the "go" sign, and which one has "leave".
>
> Question 2. Ambiguity between `(a, b) match ...` and `(a, b) match ...`
>
> This is quite a obvious question, for the infamous `,` operator that
> exists.
>
> Of course, a more obvious answer is, if we explicitly see `(a, b) match
> ...` as multiple values matching-only, then comma expression matching would
> have to be `((a, b)) match ...`. But that's not so intuitive to me, because
> there's no reason `(a, b)` shouldn't be considered a valid `expr` before
> `match` in terms of clarity.
>
> And we don't have the wording for multiple values matching yet. So it's a
> bit hard to give this a clear answer.
>
> Thanks for your patience. I'm looking forward to see any answer,
> clarification, or explanation. Do point me out if there's anything wrong
> with my idea.
>

Michael Park wasn't subscribed to this email list yet, so couldn't reply
directly. Now that he's subscribed, I'm sending this as a placeholder for
him.

Barry

>

Received on 2024-11-06 21:00:55