[Version 9.0] Feature support for pattern-matching enhancements#1460
[Version 9.0] Feature support for pattern-matching enhancements#1460BillWagner wants to merge 16 commits into
Conversation
4404f2a to
d2c1cff
Compare
RexJaeschke
added
type: feature
RexJaeschke
changed the title
|
The proposal has several open issues. We need to ensure this PR matches the final decision on those questions. I've looked through the LDM notes, and here's my initial analysis:
Yes, public class or { }
or or = new or();
if (or is or)
{ }
That is the decision. Those rules are in this PR. Most of the other open questions in the speclet have resolutions documented. The only remaining issue is the diagnostic rules for relational and logical patterns. |
793032d to
63eff42
Compare
94ee79d to
b83abc0
Compare
885475d to
2aba1c7
Compare
Add support for pattern additions fix md and example update headings fix link warnings
Address the comments on specific lines in #1026.
Address the comments in the general review comment on #1026: - I did continue to use the *logical_pattern* production. We use that term in the text, and it's a good shorthand so readers don't need to snake through the grammar of *disjunctive_pattern*, *conjunctive_pattern* and *negated_pattern*. - I haven't addressed or created issues for the open questions in the proposal yet.
Add the subsumption and exhaustiveness rules for the new patterns in V9. The subsumption/exhaustiveness rules in the Roslyn compiler use a BDD (binary decision diagram)-based algorithm that is more powerful than can be expressed with simple prose rules. These rules attempt to capture the *observable behavior* (what the compiler accepts/rejects) rather than the implementation algorithm. Where the compiler's algorithm is too complex to fully express (e.g., relational range analysis), the spec describes the intent and give examples.
- Removed duplicate parenthesized_pattern from the primary_pattern production
- Fixed relational pattern prose
Added a sentence after the grammar: "The relational_expression in a relational_pattern is required to evaluate to a constant value."
Replaced backtick-formatted `constant_expression` references with plain prose ("the expression", "the constant expression").
Changed `null_literal` to "a null constant" (it's a semantic constraint, not a syntactic one).
This was in the incorrect namespace
Applicability rule for type pattern: "A type pattern naming a type T is applicable to every type E for which E is pattern compatible with T (§11.2.2)." Applicability rule for relational pattern: "A relational_pattern is applicable to a type T if a suitable built-in binary relational operator is defined with both operands of type T, or if an explicit nullable or unboxing conversion exists from T to the type of the constant expression."
Update grammar test infrastructure to match new pattern rule hierarchy: - pattern : logical_pattern (was 6 direct alternatives) - New rules: primary_pattern, parenthesized_pattern, type_pattern, relational_pattern, logical_pattern, disjunctive_pattern, conjunctive_pattern, negated_pattern Changes: - GrammarTestingEnv.tgz: Updated baseline grammar and Rules modification set to handle new pattern hierarchy. TypePatternPredicate now walks up the tree through intermediate pattern nodes to find relational_expression. - Reference tree files: 'is (type' -> 'is (pattern' since ReplacePatternWithType action is no longer needed (type_pattern is now a proper grammar rule). - RightShift stderr: Added 'and', 'not', 'or' to expected token sets (new pattern operator keywords). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2aba1c7 to
c099d54
Compare
|
An earlier version of this feature is already present on |
2 participants
This includes all commits from #1026
There are a number of conversations that haven't been addressed from #1026: