feat: implement structured pattern matching with nested constructor support#275
feat: implement structured pattern matching with nested constructor support#275metalurgical wants to merge 2 commits intoBlockstreamResearch:masterfrom
Conversation
…upport Introduce a full pattern matching pipeline for match expressions, including typed pattern representation, validation, and a structured decision tree. This establishes a foundation for deterministic and type-safe match evaluation, enabling correct handling of nested patterns and complex destructuring. Additionally extract tests for parse to new file to reduce file bloat and improve maintainability
|
Quite tough to review, as a single commit contains too many changes The main reason for having smaller commits is to isolate possible regressions, so when the commit history follows the rule of a "logical sequence of clearly defined independent changes" it is easier to debug For example, if at some point a bug/regression is discovered, I can write a test and find the exact commit that introduced it This is why I have to ask you to split this MR into smaller commits |
I expect to see a way smaller commits |
I understand the concern around splitting the PR, and in many cases I would agree that smaller, separated commits improve reviewability. In this case, however, the core of the change is concentrated in:
Everything else follows from this and consists of new logic rather than modifications to existing behavior. It has been structured as a single unit so it can be reviewed in a working state. Splitting this into separate commits would likely introduce more overhead by requiring context to be reconstructed across commits and would be simpler to review as it currently is. Additionally, I did add the example case that was presented on the original issue as a test case as well for completeness (in a separate commit). Happy to discuss it further if that would help. |
2 participants
Introduce a full pattern matching pipeline for match expressions, including typed pattern representation, validation, and a structured decision tree.
This establishes a foundation for deterministic and type-safe match evaluation, enabling correct handling of nested patterns and complex destructuring.
Additionally extract tests for parse to new file to reduce file bloat and improve maintainability.
Overview Diagram
flowchart TD A["match syntax"] --> B{"Old vs New"} B -->|Old| C["2 arms only → normalize"] B -->|New| D["multiple arms → analyze → validate → compile"] C --> E["Match.left/right"] D --> EExpanded Diagram
flowchart TD A["match syntax"] --> B{"Old vs New"} B -->|Old| C1["exactly 2 arms required"] C1 --> C2["classify arm pair"] C2 --> C3["Left/Right or None/Some or False/True"] C3 --> E["Match.left/right"] B -->|New| D1["parse multiple arms"] D1 --> D2["convert to structured pattern representation"] D2 --> D3["assign types to patterns"] D3 --> D4["ensure all arms use the same match kind"] D4 --> D5["check for duplicate arms"] D5 --> D6["check for overlapping patterns"] D6 --> D7["check for unreachable arms"] D7 --> D8["check exhaustiveness"] D8 --> D9["build decision tree"] D9 --> D10["convert back to two-arm form"] D10 --> E["Match.left/right"]