4.6 KiB
C# Language Design Meeting for February 28th, 2022
Agenda
Quote of the Day
- "I want to see your all reactions to how crazy I sound"
Discussion
Ref fields
3d557a45ab/proposals/low-level-struct-improvements.md (open-issues)
Today, we looked at open questions in the ref fields proposal, specifically around tradeoffs between enforcement and the approach to the feature.
Encoding strategy
3d557a45ab/proposals/low-level-struct-improvements.md (to-use-modreqs-or-not)
Our general question here is whether to use modreqs 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
Now that we've decided on using modreqs 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 modreqs 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 modreqs 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
3d557a45ab/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.