# C# Language Design Meeting for January 24th, 2022

## Agenda

1. [Required members metadata representation](#required-members-metadata-representation)
2. [Default implementations of abstract statics](#default-implementations-of-abstract-statics)
3. [Triage](#triage)
    1. [Nested members in with and object creation](#nested-members-in-with-and-object-creation)
    2. [Binary Compat Only](#binary-compat-only)
    3. [Attribute for passing caller identity implicitly](#attribute-for-passing-caller-identity-implicitly)
    4. [Attributes on Main for top level programs](#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](https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-01-05.md#requiredmembersattribute) 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.
