On Tue, Nov 29, 2022 at 1:04 PM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Tue, Nov 29, 2022 at 12:12 PM Михаил Найденов via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>
> Hello,
> This is a soft followup of https://lists.isocpp.org/std-proposals/2022/10/4787.php
> which advertised limiting the scope of PM.
>
> In the attached proposal draft a new PM is presented, one with a limited scope and heavy reuse of syntax (no new syntax actually).

Your proposal starts off with this sentence:

> Current proposal aims to be conservative in its goals in order to make it in C++26.

But the importance of that goal presupposes that the current proposals
can't make C++26. I haven't been following anything in the pattern
matching domain much. Is there some reason to believe that syntax is
the primary thing that is holding these proposals back? And I mean
more than just the fact that they introduce new keywords which could
in theory break code. If that's a show-stopping problem, then it will
prevent these proposals from making it into *any* version of C++26.

So what's the evidence that these proposals are stalling out?

I have been following pattern matching pretty closely over the years, so let me chime in. While the design at the moment (the P1371 one, from Michael Park, David Sankel, et. al) still has some subtle and annoying issues to work out (for instance, with exhaustiveness), on the whole it's doing quite well, and I'm not sure that this paper really helps (it also repeatedly references some other PXXXX paper for motivation?).

To pick just the first proposal: pattern matching is not a switch, it has different semantics and it is a different feature. Reusing the switch keywords and the syntax around case labels and default, with different semantics, would be a mistake. That's why the existing proposals don't do that. The proposal for handling identifiers vs expressions is not even something I understand - why do I have to write "n= __", and why does "&n= __" affect the mutability? The analogy with lambdas doesn't make much sense to me - this is a very different kind of thing. In the latest suggestion in P2688, we have "x" matching an existing variable vs "let x" introducing a binding, you're suggesting "x" and "x="? Having a postfix differentiator seems like a bad idea. Note that all the patterns in P1371 are prefix and nest from left-to-right, which I think is fairly essential for comprehension (for humans).

Ultimately though, I really don't think that what pattern matching needs to succeed are more designs. I think P1371 is an excellent paper, it has wide support, and Michael has some very good suggestions in P2688 that resolve a few issues and also address what to me was one of P1371's shortcomings - the ability to use patterns in a few more important contexts. 

Barry