[API Proposal]: RequiresLocationAttribute (supporting ref readonly parameters)

[Sergio0694]

Background and motivation

As part of the new ref readonly parameters feature (dotnet/csharplang#6010), Roslyn will emit a new [RequiresLocation] attribute in some cases, all documented in the spec in that linked issue (as well as in the speclet at dotnet/csharplang#7165). This issue tracks adding the attribute to the runtime as well, so it can be shared (just like eg. [RefSafetyRules]).

API Proposal

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Parameter, AllowMultiple = false, Inherited = false)]
    public sealed class RequiresLocationAttribute : Attribute
    {
    }
}

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

As part of the new ref readonly parameters feature (dotnet/csharplang#6010), Roslyn will emit a new [RequiresLocation] attribute in some cases, all documented in the spec in that linked issue (as well as in the speclet at dotnet/csharplang#7165). This issue tracks adding the attribute to the runtime as well, so it can be shared (just like eg. [RefSafetyRules]).

API Proposal

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Parameter, AllowMultiple = false, Inherited = false)]
    public sealed class RequiresLocationAttribute : Attribute
    {
    }
}

API Usage

n/a

Alternative Designs

No response

Risks

No response

Author:	Sergio0694
Assignees:	-
Labels:	api-suggestion, area-System.Runtime.CompilerServices, untriaged
Milestone:	-

[stephentoub]

We're not going to add such an attribute until it's actually used by the language/compiler.

[Sergio0694]

Of course. This isn't meant to go to to API review yet 🙂

[tannergooding]

Why is this attributed needed? Won't the compiler be synthesizing the attribute if it doesn't exist, as it does with most of the other attributes it needs?

API review has typically rejected such attributes in the past.

[Sergio0694]

Wouldn't that be the same as with eg. [RefSafetyRules]? That's also synthesized by the compiler when missing, but the runtime does bundle it. I always assumed this was mostly to save size (ie. to avoid having multiple internal definitions in each project?), is that not the case? @jaredpar would the compiler team have a preference for this being included in the runtime or not, and/or would there be other considerations to make here to support this point one way or the other? 🙂

[jaredpar]

Why is this attributed needed?

It's necessary to differentiate between in and ref readonly parameters. See speclet details.

Won't the compiler be synthesizing the attribute if it doesn't exist, as it does with most of the other attributes it needs?

Yes. This isn't part of a modreq hence it will fall into our "use if available, synthesize otherwise" bucket. Similar to say nullable attributes.

API review has typically rejected such attributes in the past.

This particular API impacts calling conventions. True for the moment it is C# only but seems completely reasonable for other languages to follow suit in the future (for all the same reasons C# is making the change). Given that it, from my chair at least, it seems like that should be in the System.Runtime.CompilerServices namespace just as IsReadOnlyAttribute is.

The compiler does synthesize attributes into System namespaces today but that is usually only as a down targeting mechanism. Essentially we do it to make working on earlier target frameworks easier with the expectation that over time customers move to new target frameworks, the synthesis is not necessary and eventually fades to very limited use.

If we are never going to put this attribute into the runtime then I feel the S.R.CompilerServices name is wrong. That should be reserved for libraries level components. Thus we should move to Microsoft.CodeAnalysis but that is not ideal for an attribute that impacts calling convention.

Happy to hear others thoughts on this 😄

[tannergooding]

Marked as ready-for-review, but keeping in future until the language feature gets closer to completion.

We can push update the milestone and push forward as/when needed.