# C# Language Design Meeting for August 3rd, 2022

## Agenda

1. [`ref` fields specification updates](#ref-fields-specification-updates)

## Quote of the Day

- "If anyone is confused by these rules, you can hit me up anytime. I advise caffeine before the meeting."

## Discussion

### `ref` fields specification updates

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

Today, we looked at changes that have been made to the `ref` fields feature from implementation feedback. Changes 1 and 2 were approved with very little discussion. Point 3 generated much more
discussion.

In particular, we discussed the change that `` `this` for `struct` instance methods `` is now implicitly `scoped`. Part of this overlaps with the next point, that `` `ref` parameters that refer to `ref struct` types ``
should be `scoped` by default, but it goes further, making it the default for all structs, `ref` or not. The general question is: should we narrow this to just `ref struct` types? This would be a breaking change, and
we've accepted a breaking change in this feature already with the updated escape rules under the principle of reducing confusion and having the language do the right thing. This case is less clear-cut though: for the
escape rules, the general consensus is that the old defaults were wrong for nearly all methods, and real-world data indicated that very, very few such methods existed. That isn't the case for the `this` parameter on
`struct` methods though: `ImmutableArray<T>.ItemRef(int index)`, for example, would be broken by having `this` be implicitly unscoped. If we were designing the system from scratch, we might have narrowed this rule,
but given that the compat concerns are larger and the benefit isn't clear cut, we don't think we should narrow this rule.

We also took a bit of time to think about whether we were cutting off our ability to make future innovations in the space of `ref struct`s with these rules, such as allowing them in generics, implementing interfaces,
and future flow analysis improvements. We don't think that we're introducing any new problems in those spaces, so we'll proceed as is.

We did not get to points 4 and 5 today. We will discuss those over email and potentially in a future in-person LDM, if required.

#### Conclusion

Points 1-3 are approved.
