[Proposal]: Repeated Attributes in Partial Members

[RikkiGibson]

• Speclet: https://github.com/dotnet/csharplang/blob/master/proposals/repeated-attributes.md
• Discussion: Proposal: Repeated Attributes in Partial Members #8672

Summary

Allow each declaration of a partial member to independently apply an attribute not marked with [AttributeUsage(AllowMultiple = true)], as long as the attribute arguments are identical in all applications.

Motivation

When considering what attributes are present on a 'partial' method, the language unions together all the attributes in all corresponding positions on both declarations. For example, the method M below has attributes A and B.

[A]
partial void M();
[B]
partial void M() { }

This means that attributes which are not marked [AttributeUsage(AllowMultiple = true)] cannot be present across both parts:

[A]
partial void M();
[A] // error: duplicate attribute!
partial void M() { }

This presents a usability/readability issue, because some attributes are designed to inform the user and/or maintainer of the method of what pre/postconditions or invariants the method requires. For example:

public partial bool TryGetValue([NotNullWhen(true)] out object? value);
public partial bool TryGetValue(out object? value) { ... }

A partial member typically facilitates the relationship between a code generator and an end user--each party provides one of the declarations of the partial member in order for a code generator to provide functionality to the user, or for the user to access an extension point in generated code. In the situation where only one declaration is allowed to have these single-application attributes, the generator and the user can't effectively communicate their requirements to each other. If a generator produces a defining declaration with a NotNullWhen attribute, for instance, the user cannot write an implementing declaration with that same attribute, even though the postcondition is applicable to the implementation, and checked by the compiler. This creates confusion for users when tracking down the root causes of warnings or when trying to understand the behaviors of a method.