C# Language Design Meeting for May 23rd, 2022

Agenda

1. Open issues for ref fields

Quote of the Day

No particularly amusing quotes were said during this meeting, sorry.

Discussion

Open issues for ref fields

https://github.com/dotnet/csharplang/issues/1147
https://github.com/dotnet/csharplang/issues/6149

Today we looked at several open issues in ref fields.

Parsing scoped

There is analogy here to other modifiers we are adding in C# 11, such as required. For that modifier, we said that we wanted to error when types names conflict. However, local variables are more of a concern, as the name scoped is a perfectly reasonable local variable name. We would like to take the same approach for scoped as we do for required.

Conclusion

We will error when types are named scoped. We will do the parsing work to make scoped as a local name work.

ref auto properties

Just as auto-properties are a simplification on the private backing field + property scenario, a ref auto-property could be a simplification on the private backing field + ref-returning property backing scenario for ref structs. While we think this is a scenario that makes sense, we think it would require a setter/initer to actually be useful: otherwise, the user can only assign the backing ref field in their constructor. We don't have a real way to emit setters for ref-returning properties as the runtime doesn't support setters with a ref value argument. We could potentially do some emit tricks to make it work, but we think that it would be better to wait for first-class runtime support for the scenario, which can then be picked up more generally by other languages.

Conclusion

We will hold off on ref auto properties until we have ref-returning property setter support in the runtime.

Allowing ref assignment in object initializers

Finally, we looked at whether we should allow ref assignment in object initializers. We do have customers that want this: the runtime has been dogfooding a build of the feature, and this was one of their first requests. We do like it in general, but we need to think about the guardrails for requiring ref assignment will work. In particular, there could be multiple potential things that a user would want to do:

• required ref int Field; - Consumers must ref assign a location to Field.
• ref required int Prop { get; } - Consumers must assign a value to the storage location returned from Prop.

We punted on this question for required members previously, so we'll need to consider more at the next meeting.

Conclusion

Tentatively accepted, but we need to think about guardrails before confirming.