Tracking Issue for MaybeDangling

[RalfJung]

This is a tracking issue for the experimental MaybeDangling type (as per the T-lang experimental feature process). The type is described by this RFC, but we can experiment with adding the type unstably (and even using it in ManuallyDrop) before the RFC gets accepted.

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

• Implement the RFC (looking for someone who's willing to do this :)
• Finish the RFC, have it accepted
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• What are the exact validity requirements of MaybeDangling references?

(see RFC)

Implementation history

[RalfJung]

@rust-lang/opsem I realized we probably should have included t-opsem in the FCP for this RFC. Let's try to remember to do a t-opsem FCP in the PR with the initial implementation, just to make sure the team is on board.

[RalfJung]

There's an interesting open question I did not realize about the exact validity of MaybeDangling<&T>. I expected this to be just "non-null and aligned", but we might want to include "and has an address where an object of size T could actually exist" -- which would rule out being too close to the end of the address space, and might rule out more. The open question is exactly how much it should rule out.