On Tue, Nov 29, 2022 at 1:04 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Tue, Nov 29, 2022 at 12:12 PM Михаил Найденов via Std-Proposals
> <std-proposals_at_[hidden]> 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