csharplang/meetings/2022/LDM-2022-01-24.md

C# Language Design Meeting for January 24th, 2022

Agenda

1. Required members metadata representation
2. Default implementations of abstract statics
3. Triage
   1. Nested members in with and object creation
   2. Binary Compat Only
   3. Attribute for passing caller identity implicitly
   4. Attributes on Main for top level programs

Quote(s) of the Day

• "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."

Discussion

Required members metadata representation

https://github.com/dotnet/csharplang/discussions/5615#discussioncomment-1940488
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:

1. 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.
2. 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.

Conclusion

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.

Default implementations of abstract statics

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.

Conclusion

If the runtime support lands, we'll try to land the language side as well.

Triage

Nested members in with and object creation

https://github.com/dotnet/csharplang/issues/4587

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.

Conclusion

Needs more work.

Binary Compat Only

https://github.com/dotnet/csharplang/issues/4984#issuecomment-891213312

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.

Conclusion

Needs more work. Whoever looks at this should also look at a version where this is a flag on ObsoleteAttribute.

Attribute for passing caller identity implicitly

https://github.com/dotnet/csharplang/issues/4984

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.

Conclusion

Needs more work.

Attributes on Main for top level programs

https://github.com/dotnet/csharplang/issues/5045

This is important to unblocking partner scenarios, and we will be starting implementation shortly.

Conclusion

Working set.