C++ Logo


Advanced search

Re: [std-proposals] [Proposal] Identifiers For Pattern Matching

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Sun, 12 Mar 2023 17:24:21 -0500
On Sun, Mar 12, 2023 at 4:48 AM Михаил Найденов via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello, attached is a proposal on the topic of identifiers inside pattern
> matching.
> It is a section of an old proposal I wrote few months back, which did not
> account for the existence of p2688, as well as p2211, which renders many
> sections of it no longer needed.
At a high level, it's difficult to tell what the paper is actually
proposing - since first it says talks about naturally introducing
relational patterns, then it says it's not proposing them. Then it says
it's proposing "== *expression*" as the expression pattern, but then
frequently throughout the paper == isn't used, but then you say it's
optional if it's the "last pattern" - But what does last pattern mean? When
is == mandatory and when it is optional?

I also can't tell what actual grammar you're proposing, and it doesn't help
that throughout the paper you're frequently using the same identifier to
mean both a type and a variable name, which makes it hard to tell what the
patterns even mean. I'm not sure why that case is interesting to begin
with, much less needs to be so prevalent. There's no ambiguity to the
compiler in the Alternative Pattern for <x>, it might be ambiguous to the
reader, but not to the compiler. In the same way that template <T V> could
be a constrained type (if T names a concept), or a non-type template
parameter (if T names a type), or a deduced non-type template parameter (if
T is a template-id).

I'm assuming that the proposal is:

   - the alternate pattern is *type-id pattern*
   - the expression pattern is == *expression *(except sometimes not? I
   don't understand when you would need the ==)
   - the identifier pattern is either *identifier=* or &*identifier*=

P2688 has a lot of examples that are both short and complete. I would
encourage you to simply use those.

But ultimately we're *just *talking about a change in syntax? What's wrong
with the syntax proposed in P2688? I don't really see much of an argument
there, except that you don't like the <>s used by the alternative pattern
in P1371/P2688?
Concretely, I don't think the syntax n= syntax for bindings is particularly
good. Your model is init-capture in lambdas, but init-capture is lambdas
isn't at all the same thing as bindings in a pattern, so I'm not sure that
it's a good model. Having a distinct syntax for mutable vs immutable
bindings is interesting, but I'm not sure & is a good syntax to indicate
mutability. And if you always have a marker for the identifier pattern,
we're just talking about the difference between "let x" and "x=", so I
don't think you'd need the "==" for the expression pattern ever. The issue
largely becomes a question of disambiguating types.

Received on 2023-03-12 22:24:35