Date: Wed, 6 Nov 2024 13:14:42 -0800
On Wed, Nov 6, 2024 at 1:01 PM Barry Revzin via Std-Discussion <
std-discussion_at_[hidden]> wrote:
>
> 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".
>>
>
The short answer: the latest proposal, P2688R3
<https://isocpp.org/files/papers/P2688R3.html#updates-r2-r3>, now just
relies on std::tuple facilities.
R2 had proposed {a, b} match ..., and I discovered the issue while
implementing the feature.
Described in more detail in Problem with *braced-init-list* Syntax
<https://isocpp.org/files/papers/P2688R3.html#problem-with-the-braced-init-list-syntax>
. I then attempted (a, b) match ...
during the development of R3, which I presented in P3476R0
<https://isocpp.org/files/papers/P3476R0.pdf>. It was well received in
general,
but several implementers spoke out against this approach. A more detailed
analysis is described in
Rejected Idea: Using Parentheses for Matching Multiple Values
<https://isocpp.org/files/papers/P2688R3.html#rejected-idea-using-parentheses-for-matching-multiple-values>
.
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.
>>
>
Right, this would've been the approach. This kind of confusion is a big
reason the approach was not initially taken and
why ultimately rejected. The proposal now relies on std::tuple facilities
like: std::tie(a, b), std::tuple(1, 2), and std::forward_as_tuple(1, b).
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.
>
Thanks Barry!
Barry
>
>> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
std-discussion_at_[hidden]> wrote:
>
> 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".
>>
>
The short answer: the latest proposal, P2688R3
<https://isocpp.org/files/papers/P2688R3.html#updates-r2-r3>, now just
relies on std::tuple facilities.
R2 had proposed {a, b} match ..., and I discovered the issue while
implementing the feature.
Described in more detail in Problem with *braced-init-list* Syntax
<https://isocpp.org/files/papers/P2688R3.html#problem-with-the-braced-init-list-syntax>
. I then attempted (a, b) match ...
during the development of R3, which I presented in P3476R0
<https://isocpp.org/files/papers/P3476R0.pdf>. It was well received in
general,
but several implementers spoke out against this approach. A more detailed
analysis is described in
Rejected Idea: Using Parentheses for Matching Multiple Values
<https://isocpp.org/files/papers/P2688R3.html#rejected-idea-using-parentheses-for-matching-multiple-values>
.
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.
>>
>
Right, this would've been the approach. This kind of confusion is a big
reason the approach was not initially taken and
why ultimately rejected. The proposal now relies on std::tuple facilities
like: std::tie(a, b), std::tuple(1, 2), and std::forward_as_tuple(1, b).
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.
>
Thanks Barry!
Barry
>
>> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>
Received on 2024-11-06 21:15:21