meetings/2022/LDM-2022-08-03.md
ref fields specification updateshttps://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 structs 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.
Points 1-3 are approved.