Tracking Issue for MaybeDangling

[RalfJung]

This is a tracking issue for the MaybeDangling type, as described by this RFC.

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?
• Is there a better name? Another way to describe this type, apt for some of its usecases, is as "suppressing the implicit move constructor that some Rust types have".

(also, 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.