[Version 9.0] Feature support for pattern-matching enhancements#1460
[Version 9.0] Feature support for pattern-matching enhancements#1460BillWagner wants to merge 13 commits intodraft-v9from
Conversation
BillWagner
force-pushed
the
v9-pattern-enhancements
branch
from
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. |
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."
BillWagner
force-pushed
the
v9-pattern-enhancements
branch
from
793032d to
63eff42
Compare
2 participants
This includes all commits from #1026
There are a number of conversations that haven't been addressed from #1026: