A number of miscellaneous small issues

[BillWagner]

Followup to #1579. More small issues, where the full committee should weigh in before changes.

High Severity — Normative Contradictions

4. Fix interface access modifier contradiction — In basic-concepts.md, §7.5.2 says "No access modifiers are allowed on interface member declarations." This contradicts §7.5.4 (which discusses protected/private protected interface members) and interfaces.md §19.4 (which says "an explicit access modifier is permitted except on static constructors"). Update §7.5.2 to reflect that interface members default to public but may have explicit access modifiers.

   Verified 2.20. Fix is to remove the sentence in 7.5.2.

5. Fix "double precision" → "decimal precision" in §8.3.8 — In types.md, the decimal section says operations are "performed with double precision." The same section's subsequent text describes decimal-precision behavior, and §12.4.7.3 promotes to decimal, not double. Change to "decimal precision".

   This is a problem, but the above fix isn't correct. If both operands are decimal, the operation is a decimal. If one of the operands is decimal and the other is an integral type, the intergral type is promoted to decimal. If one operand is decimal and the other is floating point (float or double), an error occurs because there's no implicit conversion between the types. A better wording is something like "if both operations are decimal, the operations are performed with decimal precision. If one is decimal and the other is an integral type, the integral type is promoted to decimal and the operations are performed with decimal precision. If one of the operands is decimal and the other is a floating point type, an error ocurrs. (The last sentence might not be needed because that promotion is already prohibited by its absence in the defined numeric promotions.)

6. Fix "interface method" → "interface property" in §19.4.4 — In interfaces.md, the interface properties section says "An interface method declaration that has a block body or expression body as a method_body is virtual." This should describe a property declaration, parallel to the correct wording in §19.4.6 for indexers.

   "property" would be wrong. This paragraph applies to properties or property accessors. Proposal to replace "method with "interface property or interface property accessor".

7. Fix EnumeratorCancellation warning rule (enumerable/enumerator swapped) — In attributes.md, the warning rule says the attribute on a method returning an asynchronous enumerable (rather than enumerator) should warn. The example at line 1103 demonstrates exactly this usage as correct. The warning should apply when the method returns an asynchronous enumerator (where token combination is pointless), not enumerable.

   Proposal is correct..

Medium Severity — Cross-Reference Errors, Terminology, Text Corruption

15. Remove redundant "unmanaged type" from §12.17 — In expressions.md, the null coalescing operator condition mentions "unmanaged type" as a separate case from "non-nullable value type," but unmanaged types are a subset. Simplify to just "non-nullable value type."

    This is incorrect. The "unmanaged types" include pointer types. Propsal: Say "Non-nullable value type or pointer type in unsafe code".

16. Fix output-unsafe definition notation in §19.2.3.2 — In interfaces.md, the output-unsafe rule writes `Sᵢ,... Aₑ` (missing angle brackets). Change to `S<Aᵢ,... Aₑ>` to match the input-unsafe definition.

    The angle brackets should be added.

17. Fix "class or struct" → "class" in §19.6.8 — In interfaces.md, the abstract-classes-only section mentions "the class or struct." Structs cannot be abstract (§16.4.3). Remove "or struct."

    Low priority, but proposal is correct.

18. Fix using statement prose to match grammar — In statements.md, the prose says "local_variable_declaration" but the grammar uses non_ref_local_variable_declaration. Update the prose to match.

    Proposal is correct.

19. Fix pointer type prose vs grammar in §24.3 — In unsafe-code.md, the prose says unmanaged_type but the grammar uses value_type. Align the prose and grammar to use the same non-terminal.

    The grammar should use unmanaged_type. (Yes, it's legal to create pointers to pointer types.)

20. Add maybe default production to null state rules in §8.9.5.2 — In types.md, the normative rules for default null state only produce maybe null or not null — never maybe default, even though it is defined as one of three possible states and the note explains when it should apply. Add a normative rule that produces maybe default for unconstrained type parameters.

    Should the text be normative? Or, should a normative rule be added for maybe default for an unconstrained type parameter, and its state depends on the type argument?

21. Fix pattern compatibility to include nullable conversions in §11.2.2 — In patterns.md, the definition of "pattern compatible" omits wrapping/unwrapping conversions, but the example at line 117 demonstrates int? x is int v. Add nullable (wrapping/unwrapping) conversions to the definition.

    Verified. This fix should apply only to nullable value types. No conversion is needed for nullable reference types, although a note might be reasonable.

22. Qualify var pattern "matches every value" in §11.2.4 — In patterns.md, the blanket statement "A var_pattern matches every value" is contradicted by the rewrite rule at line 195 that converts var (x, y) to a positional pattern with a null check. Qualify that only var patterns with simple_designation match every value.

    This might be related to Nigel's assignment work. If it's not part of those changes, the proposal is correct.

Low Severity — Typos and Formatting

43. Remove duplicate portability entry for finalizers — In portability-issues.md: items 9 and 11 both say "Whether or not finalizers are run as part of application termination." Remove one.

    Verified. Remove the 2nd instance, but add both xrefs to the first instance (7.2 and 7.9).

44. Fix terminology inconsistency in §17.4 — In arrays.md: "array access" and "element access" used interchangeably in the same paragraph. Harmonize.

    In the second paragraph, the use of "element access" could be replaced with "array access".

45. Address ref struct restriction list structure in §16.2.3 — In structs.md: the bullet list mixes "contexts" (completing the lead-in sentence) with standalone statements. Restructure so all items are grammatically consistent with the introduction.

    Verified. This is wordsmithing. Update for consistent sentence structure.

46. Address null literal double-classification in §10.2.7/§10.2.8 — In conversions.md and conversions.md: the null literal conversion to reference types is listed both as a "null literal conversion" and as an "implicit reference conversion." Remove from §10.2.8 or note the overlap.

    We should remove from 10.2.8, but add the xref to 6.4.5.7 in the mention in 10.2.7.

47. Add cross-reference for "Explicit interface conversions" in §10.3.1 — In conversions.md: this bullet has no section reference unlike all siblings. Either add a cross-reference to §10.3.5 or merge into explicit reference conversions.

    Proposal: Add the xref to 10.3.5.

I've added comments to upvote or downvote each of these proposals. Once we have quorum, I'll make a PR for those with consensus.

[BillWagner]

4. Fix interface access modifier contradiction — In basic-concepts.md, §7.5.2 says "No access modifiers are allowed on interface member declarations." This contradicts §7.5.4 (which discusses protected/private protected interface members) and interfaces.md §19.4 (which says "an explicit access modifier is permitted except on static constructors"). Update §7.5.2 to reflect that interface members default to public but may have explicit access modifiers.

   Verified 2.20. Fix is to remove the sentence in 7.5.2.

[BillWagner]

5. Fix "double precision" → "decimal precision" in §8.3.8 — In types.md, the decimal section says operations are "performed with double precision." The same section's subsequent text describes decimal-precision behavior, and §12.4.7.3 promotes to decimal, not double. Change to "decimal precision".

   This is a problem, but the above fix isn't correct. If both operands are decimal, the operation is a decimal. If one of the operands is decimal and the other is an integral type, the intergral type is promoted to decimal. If one operand is decimal and the other is floating point (float or double), an error occurs because there's no implicit conversion between the types. A better wording is something like "if both operations are decimal, the operations are performed with decimal precision. If one is decimal and the other is an integral type, the integral type is promoted to decimal and the operations are performed with decimal precision. If one of the operands is decimal and the other is a floating point type, an error ocurrs. (The last sentence might not be needed because that promotion is already prohibited by its absence in the defined numeric promotions.)

[BillWagner]

7. Fix "interface method" → "interface property" in §19.4.4 — In interfaces.md, the interface properties section says "An interface method declaration that has a block body or expression body as a method_body is virtual." This should describe a property declaration, parallel to the correct wording in §19.4.6 for indexers.

   "property" would be wrong. This paragraph applies to properties or property accessors. Proposal to replace "method with "interface property or interface property accessor".

[BillWagner]

10. Fix EnumeratorCancellation warning rule (enumerable/enumerator swapped) — In attributes.md, the warning rule says the attribute on a method returning an asynchronous enumerable (rather than enumerator) should warn. The example at line 1103 demonstrates exactly this usage as correct. The warning should apply when the method returns an asynchronous enumerator (where token combination is pointless), not enumerable.

    Proposal is correct..

[BillWagner]

15. Remove redundant "unmanaged type" from §12.17 — In expressions.md, the null coalescing operator condition mentions "unmanaged type" as a separate case from "non-nullable value type," but unmanaged types are a subset. Simplify to just "non-nullable value type."

    This is incorrect. The "unmanaged types" include pointer types. Propsal: Say "Non-nullable value type or pointer type in unsafe code".

[BillWagner]

25. Fix output-unsafe definition notation in §19.2.3.2 — In interfaces.md, the output-unsafe rule writes `Sᵢ,... Aₑ` (missing angle brackets). Change to `S<Aᵢ,... Aₑ>` to match the input-unsafe definition.

    The angle brackets should be added.

[BillWagner]

26. Fix "class or struct" → "class" in §19.6.8 — In interfaces.md, the abstract-classes-only section mentions "the class or struct." Structs cannot be abstract (§16.4.3). Remove "or struct."

    Low priority, but proposal is correct.

[BillWagner]

27. Fix using statement prose to match grammar — In statements.md, the prose says "local_variable_declaration" but the grammar uses non_ref_local_variable_declaration. Update the prose to match.

    Proposal is correct.

[BillWagner]

29. Fix pointer type prose vs grammar in §24.3 — In unsafe-code.md, the prose says unmanaged_type but the grammar uses value_type. Align the prose and grammar to use the same non-terminal.

    The grammar should use unmanaged_type. (Yes, it's legal to create pointers to pointer types.)

[BillWagner]

30. Add maybe default production to null state rules in §8.9.5.2 — In types.md, the normative rules for default null state only produce maybe null or not null — never maybe default, even though it is defined as one of three possible states and the note explains when it should apply. Add a normative rule that produces maybe default for unconstrained type parameters.

    Should the text be normative? Or, should a normative rule be added for maybe default for an unconstrained type parameter, and its state depends on the type argument?

[BillWagner]

31. Fix pattern compatibility to include nullable conversions in §11.2.2 — In patterns.md, the definition of "pattern compatible" omits wrapping/unwrapping conversions, but the example at line 117 demonstrates int? x is int v. Add nullable (wrapping/unwrapping) conversions to the definition.

    Verified. This fix should apply only to nullable value types. No conversion is needed for nullable reference types, although a note might be reasonable.

[BillWagner]

32. Qualify var pattern "matches every value" in §11.2.4 — In patterns.md, the blanket statement "A var_pattern matches every value" is contradicted by the rewrite rule at line 195 that converts var (x, y) to a positional pattern with a null check. Qualify that only var patterns with simple_designation match every value.

    This might be related to Nigel's assignment work. If it's not part of those changes, the proposal is correct.

[BillWagner]

43. Remove duplicate portability entry for finalizers — In portability-issues.md: items 9 and 11 both say "Whether or not finalizers are run as part of application termination." Remove one.

    Verified. Remove the 2nd instance, but add both xrefs to the first instance (7.2 and 7.9).

[BillWagner]

44. Fix terminology inconsistency in §17.4 — In arrays.md: "array access" and "element access" used interchangeably in the same paragraph. Harmonize.

    In the second paragraph, the use of "element access" could be replaced with "array access".

[BillWagner]

45. Address ref struct restriction list structure in §16.2.3 — In structs.md: the bullet list mixes "contexts" (completing the lead-in sentence) with standalone statements. Restructure so all items are grammatically consistent with the introduction.

    Verified. This is wordsmithing. Update for consistent sentence structure.