# C# Language Design Meeting for May 23rd, 2022

## Agenda

1. [Open issues for `ref` fields](#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.
