TAIT decision on whether nested inner items may define

[traviscross]

To move forward on TAIT in any form, regardless of how we notate which items may or must define the hidden type of an opaque, we must decide whether the following should be true:

Unless and until RFC PR 3373 is accepted and scheduled for stabilization in some future edition, items nested inside of other items may define the hidden type for opaques declared outside of those items without those items having to recursively be allowed to define the hidden type themselves.

If not allowed, this would be called the "nested inner items restriction,"and we would be closing this door as we could not necessarily lift this restriction later after TAIT is stabilized.

As background, within the body of items, Rust today accepts impls of outer traits for outer types, e.g.:

trait Trait {}
struct S;
const _: () = {
    impl Trait for S {} // Allowed.
};

Analogously, TAIT allows inner items to define the hidden type of an opaque even if the enclosing outer item cannot define the hidden type. E.g.:

#![feature(type_alias_impl_trait)]

type Foo = impl Sized;
const _: () = { // Not allowed to define.
    static INNER: Foo = (); // Allowed to define.
};

And also:

#![feature(type_alias_impl_trait)]

type Foo = impl Sized;
fn foo() { // Not allowed to define.
    fn inner() -> Foo {} // Allowed to define.
}

For the purposes of this question, please set aside how we know that the outer item is not allowed to define the hidden type and that the inner item otherwise is; this question is invariant to the details of that.

This issue is nominated for T-lang to decide this question. Since this is mostly separable from other questions of how TAIT is designed, we propose this be decided now so as to reduce the scope of what must be considered and decided in the stabilization PR.

This question was discussed in the 2023-11-08 T-lang Mini-TAIT design meeting (minutes, rust-lang/lang-team#233).

For a full discussion of this question, see:

• Lifting nested inner items restriction
• Appendix G: Nested inner items restriction details

There was an earlier decision. Back in June, before we knew that if imposed this restriction could not later be lifted, and before we knew of other restrictions likely to be part of the stabilization of TAIT due to considerations for the new trait solver (such as a rule that any item that's allowed to define to hidden type must define the hidden type, again, setting aside how we indicate whether that is allowed), T-lang decided in the #107645 FCP to impose this restriction. Now that we know that it may not later be possible to lift such a restriction, that raises the stakes, and it seems we may want to reanalyze and reconsider this question.

[traviscross]

@rustbot labels -I-lang-nominated

Given that the situation has changed a bit here with RFC 3373 and that this issue doesn't affect ATPIT, this doesn't seem ripe for lang discussion at the moment, so let's unnominate. We can reconsider this of course if it has relevance to some future concrete TAIT proposal.