[Version 9.0] Feature support for more partial methods#1468
[Version 9.0] Feature support for more partial methods#1468BillWagner wants to merge 11 commits into
Conversation
5e7986c to
9e0a0f2
Compare
RexJaeschke
added
type: feature
RexJaeschke
changed the title
9e0a0f2 to
13eca45
Compare
BillWagner
added
the
meeting: discuss
|
This is ready for a first look from the committee. I addressed all the comments from #991. However, #991 (comment) is an instance where the spec language is correct, and the roslyn implementation has a parsing error. See dotnet/roslyn#81947. Secondly, I made more substantial edits to the original PR. The draft retained a single clause for Partial methods. Looking ahead at the future versions (for the standard), I split this into three sections: General, restricted partial methods, and unrestricted partial methods. I think that makes the text easier to read, and provides the framework for future versions where there are more unrestricted partial methods. Discussion question: I used the terms in the current PR of "restricted" and "unrestricted". I'm not convinced those are the best terms. It might be better to use "optional partial methods", and "required partial methods", respectively. I'm not sold on those either. Other thoughts? |
df85388 to
5839c04
Compare
jskeet
left a comment
jskeet
left a comment
There was a problem hiding this comment.
Overall - either optional and required are the wrong way round here, or I think we should find another pair of terms. Sorry to throw a spanner in the works!
| - Corresponding type parameters in the declarations shall have the same constraints (modulo differences in type parameter names). | ||
| - The declarations shall have the same modifiers except for the `async` and `extern` modifiers. The `async` and `extern` modifiers are allowed only on the implementing partial method declaration. | ||
| - Corresponding parameters in the declarations shall have the same modifiers (although not necessarily in the same order) and the same types (modulo differences in type parameter names). Tuple types (§8.3.11) used as parameters or return types shall have the same item names in both the defining and implementing partial method declarations. | ||
| - Corresponding type parameters in the declarations shall have the same constraints. An implementation may choose to issue a warning if the type parameter names are different in the defining and implementing declarations. |
There was a problem hiding this comment.
Do we need this bit about warnings? (I think we generally say implementations can issue warnings whenever they want.)
BillWagner
removed
the
meeting: discuss
fbe81a5 to
c403cee
Compare
…review commits Delta: 9 commits (16fa8b4..c403cee) Original: 3563471 (alpha-v9) / 3eed3e3 (pr-1468) Conflicts resolved: 2 in classes.md - Conflict 1: Replaced old 'two kinds' paragraph with new 'classified as follows' intro - Conflict 2: Replaced old 'restricted partial method' restrictions with 'default arguments' bullet (restrictions moved to §optional-partial-methods)
c403cee to
84fff65
Compare
fix md formatting revert to previous text handle imp/exp private allow partial with ref_kind returns change link's target name
Also, edit after moving text around.
Clean up a bit of language and flow.
Co-authored-by: Jon Skeet <jonskeet@google.com>
Investigate and respond to feedback from reviews. Implement the proposed name change to "optional" and "required"
Co-authored-by: Jon Skeet <jonskeet@google.com>
84fff65 to
db72bd2
Compare
|
An earlier version of this feature is already present on |
- Add that return types must match. - Add rule on type parameter constraints. - Add text for extern implementations.
3 participants
This PR replaces #991
There are several unaddressed comments on #991: