Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal]: Repeated Attributes in Partial Members #8673

Open
RikkiGibson opened this issue Nov 22, 2024 · 0 comments
Open

[Proposal]: Repeated Attributes in Partial Members #8673

RikkiGibson opened this issue Nov 22, 2024 · 0 comments
Assignees
Labels
Needs Implementation The specification for this issue has been approved, it needs an implementation Proposal champion
Milestone

Comments

@RikkiGibson
Copy link
Contributor

RikkiGibson commented Nov 22, 2024

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.

@RikkiGibson RikkiGibson self-assigned this Nov 22, 2024
@RikkiGibson RikkiGibson added this to the Any Time milestone Nov 22, 2024
@RikkiGibson RikkiGibson added Proposal champion Needs Implementation The specification for this issue has been approved, it needs an implementation labels Nov 22, 2024
@dotnet dotnet locked and limited conversation to collaborators Nov 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs Implementation The specification for this issue has been approved, it needs an implementation Proposal champion
Projects
None yet
Development

No branches or pull requests

1 participant