# C# Language Design Meeting for February 28th, 2022

## Agenda

1. [Ref fields](#ref-fields)
    1. [Encoding strategy](#encoding-strategy)
    2. [Keywords vs Attributes](#keywords-vs-attributes)
    3. [Breaking existing lifetime rules](#breaking-existing-lifetime-rules)

## Quote of the Day

- "I want to see your all reactions to how crazy I sound"

## Discussion

### Ref fields

https://github.com/dotnet/csharplang/blob/3d557a45ab03597aca4ccc24ba6eaacbcc930431/proposals/low-level-struct-improvements.md#open-issues

Today, we looked at open questions in the `ref field`s proposal, specifically around tradeoffs between enforcement and the approach to the feature.

#### Encoding strategy

https://github.com/dotnet/csharplang/blob/3d557a45ab03597aca4ccc24ba6eaacbcc930431/proposals/low-level-struct-improvements.md#to-use-modreqs-or-not

Our general question here is whether to use `modreq`s as the encoding mechanism for the various semantic elements of the feature, or if we should instead
use attributes. Using attributes as the encoding mechanism would allow APIs to evolve their surface areas without a binary breaking change later: for
example, if a library forgot to add `DoesNotEscape` (or whatever the final syntax for such a thing ends up being), they could add that attribute later
without it being a binary-break to do so. We therefore need to decide whether we consider such elements an integral part of the method signature, and
whether this compat scenario is something we feel is likely. After a bit of discussion, we concluded that, except for potentially as part of the initial
attribution of existing BCL methods, the idea that something does or does not escape is integral to the design of a method, and we don't find it likely
that there will be a general need to change the ref struct capturing of a method after it shipped. Meanwhile, `modreq` gives us much stronger enforcement
of the safety rules, and the safety rules are integral to avoiding all sorts of memory safety issues. It is better in this area for a binary break to
occur than for an accidental RCE to be opened because memory escaped where it wasn't expected to on binary upgrade.

##### Conclusion

We will use modreqs for encoding the safety rules.

#### Keywords vs Attributes

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

Now that we've decided on using `modreq`s as the encoding mechanism, we can look at how they should be applied by a user. This is going to be a complex
area for this feature: there are entire languages (ie Rust, M#, and others) that ingrain lifetime management into the language itself, from the very
beginning. The initial proposal used attributes as the syntax, and they do have some advantages: they can be sufficiently wordy without seeming unnatural,
and we don't have to invent a syntax for a niche of the language. However, given that we have now decided to use `modreq`s as the encoding mechanism
for the feature, using attributes seems the wrong approach. Attributes never affect the encoded signature of a method (ie, what is emitted as part of
a `call` or `callvirt` instruction), while `modreq`s do. This would set an unfortunate precedent and complicate both the compiler and user understanding
of what is actually part of a signature. We think this is something that should be avoided.

##### Conclusion

We will explore the dedicated syntax space. We're open to ideas here: anything from specific keywords to more complex lifetime tracking syntax are things
we will look at.

#### Breaking existing lifetime rules

https://github.com/dotnet/csharplang/blob/3d557a45ab03597aca4ccc24ba6eaacbcc930431/proposals/low-level-struct-improvements.md#take-the-breaking-change

Our existing lifetime rules are both complex and somewhat inconsistent, which leads to confusion for all levels of users. We'd like to fix it, but it will
require taking a breaking change. Our advantage here is that the users who are authoring these APIs are mostly the BCL, or avid followers of the language
and improvements. Informal surveys of these populations have indicated receptiveness to taking this breaking change to simplify the surface area. It may
also be possible to structure the breaking changes such that the actual C# written gets simpler, but the metadata is more compatible with the existing
format today (ie, not changing the meaning of existing metadata, but changing what metadata existing source will compile down to). This would make the
compiler implementation more complex, but it might be a good compromise to allow existing code to continue to exist safely.

##### Conclusion

We are willing to consider breaks to the area to simplify the existing rules.
