[Version 9.0] Feature support for more partial methods#1468
[Version 9.0] Feature support for more partial methods#1468BillWagner wants to merge 10 commits intodraft-v9from
Conversation
BillWagner
force-pushed
the
v9-more-partial-methods
branch
from
5e7986c to
9e0a0f2
Compare
RexJaeschke
added
type: feature
RexJaeschke
changed the title
BillWagner
force-pushed
the
v9-more-partial-methods
branch
from
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? |
BillWagner
requested review from
Nigel-Ecma,
RexJaeschke,
ericlippert,
gafter,
jnm2 and
jskeet
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.
BillWagner
force-pushed
the
v9-more-partial-methods
branch
from
df85388 to
5839c04
Compare
Co-authored-by: Jon Skeet <jonskeet@google.com>
Investigate and respond to feedback from reviews. Implement the proposed name change to "optional" and "required"
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.)
Co-authored-by: Jon Skeet <jonskeet@google.com>
3 participants
This PR replaces #991
There are several unaddressed comments on #991: