Unsafe Fields

[nikomatsakis]

Metadata
Point of contact	@jswrenn
Team(s)	compiler, lang
Goal document	2025h1/unsafe-fields

Summary

Design and implement a mechanism for denoting when fields carry library safety invariants.

Tasks and status

• Discussion and moral support (lang )
• Author RFC (@jhpratt)
• Implementation (@veluca93)
• Standard reviews (compiler )
• Design meeting (lang )
• Lang-team champion (lang )
• RFC decision (lang )

[nikomatsakis]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[jswrenn]

Key developments: In a Feb 19 Lang Team Design Meeting, we reached consensus that the MVP for unsafe fields should be limited to additive invariants.

[jswrenn]

Key developments: After the last lang team meeting, Ralf observed that the additive/subtractive dichotomy (and its attendant design concerns w.r.t. Drop) could be sidestepped, since a field type already cannot be put into an unsound-to-drop state without unsafe code. With this observation, we can reduce field safety tooling to two rules:

1. a field should be marked unsafe if it carries a safety invariant (of any kind)
2. a field marked unsafe is unsafe to use

The RFC now reflects this design and has more or less reached a fixed point. Ongoing discussion on the RFC is now mostly limited to weighing this design against a proposed alternative that mixes syntactically knobs and wrapper types. The RFC would benefit from formal review by @rust-lang/lang.

[jswrenn]

Key developments: No significant developments since previous updates.

Blockers: Waiting on lang team review.