Add unsafe binder types to the compiler

[compiler-errors]

Proposal

I would like to add unsafe binder types to the language as a T-lang experiment. Please read this document I wrote up for some motivation: https://hackmd.io/rAyz9MURTlazMdnffl2uSQ.

I probably don't need to go into detail about the desired semantics, but briefly: An unsafe binder type is written like unsafe<'a, 'b> Ty<'a, 'b> or unsafe<'r> &'r i32, with any number of bound variables in the unsafe<...> followed by a type which may reference those bound variables. Unsafe binder types are a distinct types from their wrapped type (Ty<'a, 'b>); they have no subtyping relationship, no automatic coercion, and user-written impls cannot be implemented on them. They will, however, inherit the layout and act as much as possible like a repr(transparent) wrapper around their wrapped type, and may have some built-in implementations (such as Sized). They can be interconverted using two unsafe macro-based operators wrap_unsafe!(expr) and unwrap_unsafe!(expr) which are unsafe to use.

This MCP does not guarantee that they will remain in the compiler forever, or move towards any stabilization without an RFC first, and that RFC will certainly have T-types on it. At any point, we as a team can decide to remove them from the compiler just like any other nightly feature. This feature will remain marked incomplete, and it should not be used in the standard library without an RFC first, or at least further team consensus (and likely an FCP of its own, at the very least).

Mentors or Reviewers

I will implement unsafe binders and I will need no mentorship obviously.

@BoxyUwU has expressed interest in reviewing unsafe binder types, but I will also try to break out anything that's not totally types facing such as parsing, name resolution, and diagnostics to the general reviewer pool in T-compiler.

Process

The main points of the Major Change Process are as follows:

• [x] File an issue describing the proposal.
• [ ] A types team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Types team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

 @rustbot concern reason-for-concern 
 <description of the concern> 

Concerns can be lifted with:

 @rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/types

[BoxyUwU]

@rustbot second

[compiler-errors]

It has been 10 days, so this is accepted.