Hello, P1371R3 was the previous iteration of pattern matching. The most recent version

discussed in EWG was P2688R5, which did not achieve consensus for C++26.

I'm currently working on R6 of P2688, which I will be submitting for the upcoming Sept mailing.

I'm planning to present it in Buzios in November, and targeting C++29.

As a small preview, with R6 the code you wrote:

switch (x) { // Assume x is of type std::variant<MyClass, int>
case (MyClass myclass): { a(myclass); break; }
case (int n): { b(n); break; }
}

would be written like this (CE link: https://godbolt.org/z/fMW1xdjz6):

match (x) { // Assume x is of type std::variant<MyClass, int>
  case { MyClass myclass } => a(myclass);
  case { int n } => b(n);
}

The semantics are slightly different, as these do not form an overload set. They are still matched
in order top-to-bottom, and require exact match. As such, for examples like this, it works out to be
the same (you can reorder the handlers in the match example, it's the same).

The braces denote that we're matching the element inside the variant. Without the braces,
it matches the whole variant rather than the stored element.

match (x) { // Assume x is of type std::variant<MyClass, int>
  case { auto elem } => c(elem);
  // vs
  case auto whole => d(whole);
}

This distinction of payload vs whole extends to optional for example as well:

match (opt) { // Assume opt is of type std::optional<int>
  case {} => ; // nullopt
  case { auto elem } => ; // elem is int
  // vs
  case auto whole => ; // whole is optional<int>
}

There's... A LOT more to share, but this is one of the important core ideas of R6.

On Thu, Sep 10, 2026 at 3:49 PM Jefferson Carpenter via Std-Discussion <std-discussion@lists.isocpp.org> wrote:

Actually the two are more or less the same. I think it would be much
more readable to allow a statement-seq ending with a retrun statement
to provide the value like a lambda expression than to try to construct
matchers and extractors for whatever intermediate values you need.

On Thu, Sep 10, 2026 at 5:07 PM Jefferson Carpenter
<jeffersoncarpenter2@gmail.com> wrote:
>
> I definitely agree that matchers and extractors should not be language
> features. Implementing these is like trying to invert a function.
>
> If the inspect expression is non-void, can a statement-seq be used
> with a return statement to implement the value?
>
> - Jefferson
>
> On Thu, Sep 10, 2026 at 4:30 PM Jefferson Carpenter
> <jeffersoncarpenter2@gmail.com> wrote:
> >
> > That looks good.
> >
> > On Thu, Sep 10, 2026 at 3:58 PM Jens Maurer <jens.maurer@gmx.net> wrote:
> > >
> > >
> > > Please read the pattern matching proposal:
> > >
> > > P1371 Pattern Matching
> > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf
> > >
> > > Jens
> > >
> > >
> > > On 9/10/26 21:05, Jefferson Carpenter via Std-Discussion wrote:
> > > > Hi all,
> > > >
> > > > I'd like to propose some "syntactic sugar" that ties the switch
> > > > statement language feature to the std::variant standard library type.
> > > > The idea is to make the process of visiting a variant much cleaner and
> > > > simpler.
> > > >
> > > > Basically it has to support the following code transformation:
> > > >
> > > > switch (x) { // Assume x is of type std::variant<MyClass, int>
> > > > case (MyClass myclass): { a(myclass); break; }
> > > > case (int n): { b(n); break; }
> > > > }
> > > >
> > > > to the following:
> > > >
> > > > struct Unnamed {
> > > > void operator()(MyClass const& myclass) { a(myclass); }
> > > > void operator()(int const& n) { b(n); }
> > > > };
> > > > Unnamed{}(x);
> > > >
> > > > so that the code jumped to from each case is transformed into a
> > > > function call operator overload. A braced-enclosed code block ending
> > > > in a break statement may be required after each case "label" even when
> > > > there are no variables declared in the body or if fallthrough were
> > > > desired so that the code that must be moved is outlined and easy to
> > > > move.
> > > >
> > > > This could potentially be extended to other non-std::variant types if
> > > > there were a mechanism like std::get, but I haven't explored this at
> > > > all.
> > > >
> > > >
> > > > This would be very useful to me, as I've written a lot of
> > > > programming-language-like programs and use std::variant extensively to
> > > > represent expression trees.
> > > >
> > > > It would make C++ much more viable for programs like this to have the
> > > > code for visitors easier to read and type than calls to std::visit.
> > > >
> > > >
> > > > Warm Regards,
> > > > Jefferson Carpenter
> > >
--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion