Pattern matching syntax and semantics

[zygoloid]

This paper proposes concrete syntax and semantic choices for Carbon patterns.

[micttyl]

I need to read more to understand. This is because I haven't caught up the current state of Carbon.

[micttyl]

It is clear.

[micttyl]

Thank you. Understood. Confusing though.

[micttyl]

Can you show the use case of unused

[zygoloid]

There is now an example of this a little later in the proposal, plus a cross-reference to #2022 which introduces this keyword.

[geoffromer]

This is a proposal for pattern matching syntax and semantics, though. Even at the syntactic level, they're closely connected: a deduced parameter list always comes immediately before a pattern, and always consists of a list of binding patterns. At the semantic level, it's not just that the behavior of the two is "similar", it's that they are directly coupled: as far as I can tell, type deduction is always driven by a pattern matching operation, and I think it can feed back into that pattern matching operation.

To be clear, I'm not saying this proposal needs to have a design for type deduction; I just don't think type deduction is as cleanly separable from pattern matching as this makes it sound.

[zygoloid]

I don't think they're necessarily coupled. I think we are confident that we're going to do deduction when performing function calls to generic functions and when selecting an impl. I think we are confident that we're going to do pattern matching in a match statement and in a let or var binding. I don't think it's guaranteed that we'll do pattern matching in a function call -- it may be reasonable to restrict a function to have only a list of bindings as its parameters, which only needs pattern matching in a degenerate sense, and I think we're not going to do pattern matching in impl selection. So I think there might actually be no situations where we perform both type deduction and non-degenerate pattern matching.

I also think it's possible that we'll model the matching process for the two cases quite differently: for pattern matching, we have a top-down process where the pattern syntax determines what happens at each level (such as evaluating an expression pattern and performing an == comparison, or converting the scrutinee), whereas for type deduction I think it's likely we'll instead perform a symbolic evaluation of the type expression (the "pattern") and perform a value comparison between (symbolic) type values to find a set of substitutions. The difference is fairly subtle, but I think deduction ends up having stricter matching semantics than a pattern match -- identical after substitution versus a looser notion of "match".

[geoffromer]

So I think there might actually be no situations where we perform both type deduction and non-degenerate pattern matching.

It seems like variadic functions will be such a situation. Maybe we can say that semantically, variadics relate only to deduction, and not pattern matching (although I'm not sure of that), but syntactically they're going to appear in the parentheses as well as the square brackets.

[camio]

I looked at all the changes since my prior review and they look good to me.

I'm hesitant to copy and translate someone else's work without permission from all the authors. Maybe I can use those as inspiration at least.

Most of those examples come from my paper https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0095r1.html. Feel free to use them. The red-black tree example from the newer paper was also written by me, so feel free to use that one as well.

[zygoloid]

Most of those examples come from my paper https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0095r1.html. Feel free to use them. The red-black tree example from the newer paper was also written by me, so feel free to use that one as well.

Thanks, added!

[chandlerc]

Really awesome to see all of this coming together.

I do still have a few areas I'd like to push on, but to be clear I think all of these are relatively small and narrow aspects of the proposal. Even the syntactic questions, while they'll show up everywhere, are ultimately a small part of the proposal.

[chandlerc]

Maybe also mention an expression-form as future work?

[zygoloid]

Done.

[chandlerc]

I feel like this section doesn't fully capture what we're giving up without this. Is it possible to capture some of the context from the discussion leading up to this Discord message? https://discord.com/channels/655572317891461132/709488742942900284/1020559500597538886

Generally, I wonder if we want to more deeply revisit whether we can and should shift the syntax in this direction. For example, I think I see plausible solutions to the purely syntactic concerns with identifying an introducer below.

That said, I'd be happy to either move that discussion to an issue for leads, and even do that as a fix-forward with even a minor note here that we anticipate revisiting this specific aspect of the syntax to see if there are approaches that might result in an overall better model.

[zygoloid]

Added some more notes and links. I favor the fix-forward approach, given that the most promising path involves changing the syntax for where expressions to remove the other, conflicting meaning of is.

[chandlerc]

I'm not fully convinced that we should add this yet TBH.

I wonder if we'll be able to address this usecase with variadics, and with tools that also address discarding an unspecified number of tuple elements.

I lean a little bit towards maybe documenting this option but waiting to see if we instead can solve this as part of variadic patterns more generally. What do other folks think here?

The flip side is that I think this is a minor feature and easily removed if we find that variadics obviate it, so I also don't think this is a big deal either way.

[geoffromer]

Note that struct fields aren't expressions or values, so the ability to create and match packs of struct fields would be a separate, bespoke feature, not something that would emerge automatically from a more general variadics design. I don't think we've discussed having such a feature, and it's not clear to me if there are any other use cases for it (maybe metaprogramming?). So my inclination would be to keep , _ for now, and then replace it if and when we discover we want packs-of-struct-fields for other reasons.

[zygoloid]

I agree that it's not a big deal either way, because this should be easy to change later. I lean towards adding it and seeing if we can replace it with something else later, such as variadics, and similarly seeing if it gets used heavily.

[chandlerc]

Does it make sense to provide a comparison to the syntax proposed in https://wg21.link/p2392 and more generally acknowledge some of the differences in design there?

[zygoloid]

If that comparison is useful when evaluating this proposal, I can add it, but I'm a little hesitant to get too deep into comparing this with in-flight WG21 proposals. I'm a little tempted to remove the P0095R1 / P1371R3 comparisons, given that they're not comparing against an existing language.

[chandlerc]

Just officially approving for leads. The future work and other todos cover everything that I think is outstanding, and this seems like a really clear step forward.