Create partial-properties.md

[RikkiGibson]

@jcouv

The goal is to migrate the proposal details in #6420 nearer to its "final" location.

[jaredpar]

Suggested change

	A *partial property* declaration is said to be a *defining declaration* when its accessors all have semicolon bodies, and it lacks the `extern` modifier. Otherwise, it is an *implementing declaration*. A *partial property* cannot be an auto-property.
	A *partial property* declaration is said to be a *defining declaration* when its accessors all have semicolon bodies, and it lacks the `extern` modifier. Otherwise, it is an *implementing declaration*. A *partial property* definition cannot be an auto-property.

[RikkiGibson]

I think this is correct as written. Neither a defining nor implementing declaration of a partial property will cause it to be an auto-property. I'll try and break this out to improve clarity.

[jaredpar]

The required modifier is a new consideration as it can't apply to partial methods. Does that pose any particular challenges here or does it just fall out?

[RikkiGibson]

I think usage of required partial together doesn't raise new questions. It will be supported, and have the same effect as if the partial modifier was removed and the defining declaration was merged into the implementing declaration.

[jcouv]

1. We'll probably want to confirm whether partial should still be in locked position for new features (that's something we considered relaxing for existing features)
2. The structure for method_header is a bit different (partial is not inlined in the declaration, but rather inside the method_modifiers production). Should we spec it the same way for partial properties?

method_declaration
    : attributes? method_modifiers return_type method_header method_body
    | attributes? ref_method_modifiers ref_kind ref_return_type method_header
      ref_method_body
    ;

method_modifiers
    : method_modifier* 'partial'?
    ;
``` #Closed

[RikkiGibson]

I would like to address (1) in a subsequent PR, and to do so for both properties and methods in C# 13. I recall soft approval from LDM for this, and at the time I make the change I'll also follow up by email to confirm that approval.

I would prefer to not make changes for (2) at this time, as I think the spec is conveying what it is intending to with adequate clarity, and that we'll address the concern before the spec is committed to its final state for C# 13.

[jcouv]

FWIW, it looks like partial methods allow some variation in scoped (see usage of CheckValidScopedOverride in PartialMethodChecks)
Some variation in tuple names is also allowed.

[jcouv]

Were you able to dig up our rules for scoped differences?

[RikkiGibson]

Scoped is just a modifier, I am expecting the normal rules for modifier differences to apply.

[RikkiGibson]

This can be observed for partial methods here

partial class C
{
    public partial Span<int> M(Span<int> x);
    public partial Span<int> M(scoped Span<int> x) => default; // The 'scoped' modifier of parameter 'x' doesn't match partial method declaration.CS8988
    
    public partial Span<int> M2(scoped Span<int> x);
    public partial Span<int> M2(Span<int> x) => default; // The 'scoped' modifier of parameter 'x' doesn't match partial method declaration.CS8988
}

[jcouv]

It looks like we allow some variations specifically for scoped on partial method, so the normal rule of "must have the same modifiers" doesn't seem right

[RikkiGibson]

I am not aware of any permitted variations on scoped modifiers on partial methods. The method in the implementation which checks this is called CheckValidScopedOverride, which may be misleading, but it is also passing argument allowVariance: false. In other words, scoped-ness of parameters across partial methods must be exactly the same, otherwise an error (not a warning) occurs.

[jcouv]

Ah, thanks for catching that. Cool :-)

[jcouv]

Done with review pass (iteration 4)

[jcouv]

Done with review (iteration 5)

[jcouv]

LGTM Thanks (iteration 5)