Tracking issue for unsafe binder types (`unsafe_binders`)

[traviscross]

This is a tracking issue for unsafe binder types. See https://hackmd.io/@compiler-errors/HkXwoBPaR for an initial design proposal.

The feature gate for the issue is #![feature(unsafe_binders)].

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Approve as lang experiment.
  • We accepted this in the lang triage meeting on 2024-09-18.
• Accept an RFC.
• Implement in nightly.
  • Implement MIR lowering for unsafe binders #130514
• Add documentation to the dev guide.
  • See the instructions.
• Add documentation to the reference.
  • See the instructions.
• Add formatting for new syntax to the style guide.
  • See the nightly style procedure.
• Stabilize.
  • See the instructions.

Unresolved Questions

• Are unsafe binders ABI-compatible with the type they wrap? Miri currently accepts them as such but that should be either stably documented or removed from Miri.
• Terminology. This seems to be just an existential lifetime. Why come up with a new term?

Related

• Use a trait to enforce field validity for union fields + unsafe fields + unsafe<> binder types #136660
• Unsafe binder support in rustdoc #134857
• Begin to implement type system layer of unsafe binders #134625
• Add AST support for unsafe binders #134140
• Implement MIR lowering for unsafe binders #130514

cc @compiler-errors @rust-lang/lang

[scottmcm]

I'll second this. I think that having unsafe<'a> &'a T is a nice way to keep some of the properties we want from references without falling all the way down to pointers that lose various things.

I'll be curious to see what happens with things like what the validity invariants are and what LLVM attribute parameters it could still have, but that sounds like a great thing to experiment with.

[traviscross]

We accepted this experiment in the 2024-09-18 lang triage meeting.

Thanks to @compiler-errors for pushing this forward.