# C# Language Design Meeting for October 5th, 2022

## Agenda

- [Review of `ref` fields](#review-of-ref-fields)
    - [`RefSafetyRulesAttribute`](#refsafetyrulesattribute)
    - [Return-only scope](#return-only-scope)

## Quote(s) of the Day

- "We looked at that in 7.2 and said 'We can't imagine making that work in the compiler'"
- All the facial expressions various LDM members made as they wrapped their heads around the rules.

## Discussion

We intend to post the slide deck that was shown to LDM at a later date, but it needs a few more revisions before posting.

### Review of `ref` fields

https://github.com/dotnet/csharplang/blob/main/proposals/low-level-struct-improvements.md

The `ref` fields feature has been going under significant and rapid revision as we approach the end of the C# 11 development cycle, based on
feedback from dogfooding the feature in (hopefully) its largest consumer, the BCL. RC1, however, had a few more internal and external partners
intake the bits, see the breaking changes, and give us feedback on them. Today we wanted to go over the changes we've made in response to this
latest round of feedback. The team came with a [presentation](TODO) on the recent changes for us to go over today.

#### `RefSafetyRulesAttribute`

This attribute will allow us to better recognize whether a module should be treated with the new ref safety rules, or with the pre-C# 11 safety
rules. We did have some concerns about the particular format, but these were resolved through discussion:

* This could be seen as a stamp of "this module was compiled with language version X", which isn't something we do today. However, we don't expect
the safety rules to increase every language version, so we don't expect that this will be a problem.
* We also thought about using something other than an integer, in case we have a minor version that we want to rev the rules on. We don't think
this is likely, as we've moved away from minor releases at this point.
* We thought about an analyzer to inform users about the breaking change on upgrading their assembly, this is tracked by
https://github.com/dotnet/roslyn/issues/64344.

#### Return-only scope

In response to breaking changes seen by customers with `ref` parameters, we added a new scope in between the method scope and the calling function
scope: return-only. Something that is return-only is only allowed to escape by ref through a `ref`-return or an out parameter, and not through ref
assignment to a `ref` parameter. The LDM members not steeped in the lingo of ref safety found this change particularly hard to understand, and the
ref fields group would like to brainstorm a bit on how to better explain the concept. Once the intuition was built, however, it was well-liked. In
particular, we are happy that constructors are no longer a special case, and just fall out of the new rules. We would like to see some improvement
in the error messages the compiler gives, and that work is planned for VS 17.5.
