Repository: rust
Issue: Tracking Issue for Restrictions
Labels: B-RFC-approved,T-lang,C-tracking-issue,F-impl_restriction,F-mut_restriction

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This is a tracking issue for the RFC "Restrictions" (rust-lang/rfcs#3323).
The feature gates for the issue are:
* `#![feature(impl_restriction)]`
* `#![feature(mut_restriction)]`

### 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
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [ ] Implement the RFC (@jhpratt has a branch in progress)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

- [ ] Should a simpler syntax be provided for common cases? For instance, `sealed` or `readonly`. A
  different syntax altogether could be used as well.
  - Also see https://github.com/rust-lang/rfcs/pull/3323#issuecomment-1320747457.
- [ ] Should an "unnecessary restriction" lint be introduced? It would fire when the restriction is as
  strict or less strict than the visibility. This warning could also be used for `pub(self)`.
  - Does this necessarily have to be decided as part of this RFC?
- [ ] How will restrictions work with `macro_rules!` matchers? There is currently a `vis` matcher, but
  it is likely unwise to add a new matcher for each restriction.
  - The proposed syntax cannot be added to the `vis` matcher, as it does not current restrict the
    tokens that can follow. For this reason, it could break existing code, such as the following
    example.
    ```rust
    macro_rules! foo {
        ($v:vis impl(crate) trait Foo) => {}
    }
    foo!(pub impl(crate) trait Foo);
    ```
  - A `restriction` matcher could work, but restrictions are not the same everywhere.
  - `mut_restriction` and `impl_restriction` are relatively long.
- [ ] What is the interaction between stability and restrictions?
  - Suggestion: Visibility is an inherent part of the item; restrictions should be as well. Metadata
    can be added in the future indicating when an item had its restriction lifted, if applicable.
    The design for this is left to the language team as necessary. A decision does _not_ need to be
    made prior to stabilization, as stability attributes are not stable in their own right.
- [ ] Should the `in` syntax be permitted for restrictions? Including it is consistent with the existing
  syntax for visibility. Further, the lack of inclusion would lead to continued use of the
  workaround for `impl`. For `mut`, there is no workaround. The syntax is not used often for
  visibility, but it is very useful when it is used.
- [ ] Should `struct` expressions be disallowed?
  - Where would it be desirable to prohibit mutability after construction, but still permit
    construction with unchecked values?

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- [ ] https://github.com/rust-lang/rust/pull/106074