csharplang/meetings/2022/LDM-2022-10-05.md

2.9 KiB

C# Language Design Meeting for October 5th, 2022

Agenda

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 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.