- "More knowledgeable, but scared is how I like to live my life"
- "My new goal is to be able to say C# 11 has a 'spaceship operator'. I don't care what it does."
#5615 (comment)
https://github.com/dotnet/csharplang/blob/main/proposals/required-members.md
Last time we discussed the metadata for required
members, we had indicated that we tentatively preferred a single RequiredMembersAttribute on a type, which listed strings for each member in the type that
was required. We had not considered a couple of potential issues with this, however:
- IL is allowed to duplicate names for members, so long as the members are of a different kind. IE, a field and a property with the same name is perfectly legal in IL.
- Non-compiler usages might become more difficult. Doc generation, for example, will want to be able to list the required members for a type, and reflection will likely want to represent whether a member is required in that member reflection info. While still doable with the class-based attribute, it requires more work than just looking on the member for an attribute.
We did have some initial concern with the many attribute approach that it would potentially impact load times for assemblies, like nullable was going to before
we invested in a compression strategy. After discussion with the runtime folks, however, we came to the conclusion that this is likely minimally concerning,
as there won't be nearly the proliferation of these attributes that NullableAttribute would have had as originally designed. Thus, to make implementation and
consumption simpler, we will go with the RequiredMemberAttribute on every member that is required, and on a type that defines required members.
We will adjust the specification to put a RequiredMemberAttribute on every member that is marked required, and to put it on any type that contains such members.
As part of determining our C# 11 focuses, we wanted to discuss default implementations for abstract statics, and whether we want to try and get them in during C# 11, or in some future version of C#. Part of this is, of course, runtime dependent; if support isn't there, there's nothing for the language or compiler to implement. From looking at our motivating scenarios, we have some comments on DIMs:
- They're an important library design tool. Generic math would like to use them in a few scenarios, but it's not a "critical" feature to have in V1. If they slipped to C# 12, the scenario would be ok.
- The ability to call base implementations is not a concern from a library design tool, and likely will not be designed for C# 11. We need to make sure to account for the ability to call base DIMs for instance methods as well, so this is a bigger feature. We'll let prioritization be driven by user request.
If the runtime support lands, we'll try to land the language side as well.
There is some confusion around this proposal in with expression: what are the semantics going to be? In object initializers, nested member initializers do not
create new objects, they just assign to existing ones. This makes the presented with syntax confusing, and we think it needs more workshopping. A potential
alternative could be something like a with { Member with { ... } } to imply the nested withing, but this needs to be explored and fleshed out a bit more before
we are ready to commit to accepting the proposal.
Needs more work.
As part of the next issue, we heard about a nascent proposal around the ability to mark a method as for binary compatability only, removing it from overload resolution entirely. We think the idea has merit, but need to see a complete proposal on this before we move forward.
Needs more work. Whoever looks at this should also look at a version where this is a flag on ObsoleteAttribute.
This attribute is useful for the BCL team and expands our caller info attributes. While we do have some reservations on how useful it will be until we get the above binary compat only ability, we think this is fine. Some small details left to work out before we can add it to the working set or backlog though.
Needs more work.
This is important to unblocking partner scenarios, and we will be starting implementation shortly.
Working set.