Michael Park

@facebook engineer, @isocpp member, @llvmorg committer, @apachemesos committer

[Michael Park @mcypark]

An implementation of the latest C++ pattern matching proposal (https://t.co/qNTlHgMr5T), `match` expression, is available on Compiler Explorer!

Most of the proposed patterns and constant evaluation are implemented.

Example link: https://t.co/yje582xqI3

[Michael Park @mcypark]

@skender @ChShersh This unfortunately did not make C++26. I'll be working on it for C++29, but we shall see. What is that https://t.co/IyZswlsKlo thing...? It looks like some AI made up the entire thing? 😂

[Michael Park @mcypark]

@banisterfiend (3) If it's a variant-like type, opt into variant-like protocol and you can match against it using the `type: pattern` syntax. (3) If it's a tuple-like type, opt into tuple-like protocol (same as structured bindings) and use the `[p1, p2, ...]` syntax

[Michael Park @mcypark]

An implementation of the latest C++ pattern matching proposal (https://t.co/qNTlHgMr5T), `match` expression, is available on Compiler Explorer!

Most of the proposed patterns and constant evaluation are implemented.

Example link: https://t.co/yje582xqI3

[Michael Park @mcypark]

@banisterfiend Many ways to do this depending on what your type is like. (1) If it has `operator==`, then constant values of those types can be matched against. (2) If it's an pointer-like type (converts to bool and can be dereferenced), then the `?` pattern will work

[Michael Park @mcypark]

@3alawi_almutawa @WeLostThe_Sea @stackcook That's exactly the kinds of follow-up questions that make this direction complicated. Also need to consider constraints, marking it constexpr, what kind of initialization to use, whether to allow conversions, etc.

I'm more-so open to a simple, cvref-auto only approach.

[Michael Park @mcypark]

@3alawi_almutawa @WeLostThe_Sea @stackcook Oh, okay. so you're also asking for cvref-auto. As I said, I'm still open to that direction. Yes, by cvref-auto I mean the different variations of auto, auto&, const auto&, auto&&, etc. This imo is not changing the meaning of auto within pattern matching.

[Michael Park @mcypark]

@3alawi_almutawa @WeLostThe_Sea @stackcook From my experience, virtually everyone who ask "why not auto" want cvref-auto. I have asked folks over the years about contextually changing the meaning of `auto` within pattern matching and it generally is not received well. Just my experience of course.

[Michael Park @mcypark]

@3alawi_almutawa @WeLostThe_Sea @stackcook Yes, the committee decided they have similar enough semantics.

```
pair<int, int> p = {101, 202};
p match {
[101, auto x] => x = 42;
_ => -1;
};

// p == {101, 42} here.
```

I really don't find that to be similar enough. But I think we already agreed to disagree on that

[Michael Park @mcypark]

@3alawi_almutawa @WeLostThe_Sea @stackcook Yeah, that's fine of course. I wasn't sure because you pointed out function auto arguments as an example which doesn't have different semantics with respect to lifetimes. Was that screenshot an interaction with me by the way? Apologies if I'm just not remembering

[Michael Park @mcypark]

@qmiVirgil Structured bindings in their full potential is effectively a single pattern match. Similar to Rust's `let PATTERN = Init;`. We can certainly extend structured bindings, but it still doesn't get us a branching pattern match. I do still plan to propose nested SB though, for example

[Michael Park @mcypark]

@3alawi_almutawa @WeLostThe_Sea @stackcook Yeah, one option is to make `auto` just mean `let` but that introduces new semantics for `auto` inconsistent with the rest of the language (including auto function arguments). I'm very against this. Another option is to use cvref-`auto` instead of `let`, which I'm more open to.

[Michael Park @mcypark]

@jrqcarpenter 😂

[Michael Park @mcypark]

@stackcook It's proposed to be a context-sensitive keyword in pattern context.

[Michael Park @mcypark]

@Nekrolm Exhaustive checking is not implemented yet, but the goal is to enforce it on bool, enum, optionals, variant-like, and tuples. There's a question of whether the remaining cases should be required to have a `_`. The weird cases like `valueless_by_exception` invokes `std::terminate`

[Michael Park @mcypark]

Matching Optionals (if-let-style): https://t.co/3tnDGwnR5T

#cpp

[Michael Park @mcypark]

Matching Optionals: https://t.co/PmkwBv6AIc

#cpp

[Michael Park @mcypark]

@evilissimo @hankadusikova It's "a thing" in the sense that it's part of the latest proposal for pattern matching (https://t.co/qNTlHgMr5T)