TAIT defining scope options

[oli-obk]

during the stabilization of TAITs (type alias impl trait) in #63063 (comment) a concern was raised: it's not obvious for the compiler (and IDEs), which items' bodies are allowed to register hidden types for TAITs. For RPIT (return position impl trait) it was obvious: the body of the function in whose return type the impl Trait was in. For TAITs the status quo is point 1 in the list of options below. This may require some interesting module juggling to avoid cycle errors that can occur due to revealing the hidden type to prove Send or Sync bounds, and that revealing again looking at the item to look for things registering the hidden type (see example and passing example).

The possible schemes we know about currently are:

1. any item that is (recursively) within the parent of the TAIT is allowed to register the hidden type
2. any item that follows the rules of 1. and additionally has the TAIT in its signature or where bounds is allowed to register the hidden type. this change has a prospective impl at
   • Require TAITs to appear in the signature of items that register a hidden type #107073
   • not much wiggle room for changing things after stabilization, as any change can quickly leed to then-stable code to have cycle errors
3. same as 2. but not permitting where bounds to register hidden types
4. any item in the defining scope can register hidden types, but we error out if the TAIT is not mentioned in the signature or where bounds
   • Require TAITs to appear in the signature of items that register a hidden type #107809
   • similar to 2., but since we still look at all functions in the defining scope, there's no change in cycle errors to 1.
   • forward compatible with choosing 2. or 1. later
5. same as 4. but not permitting where bounds to register hidden types
   • forward compatible with choosing 4. later

Ruled out schemes:

6. any item that follows the rules of 1. and has a #[defines(NameOfTheTypeAlias)] attribute is allowed to register the hidden type
   • probably undesirable due to the verbosity in "obvious" cases (like using a TAIT in function return position)
7. only allow explicitly registering hidden types with a magic libcore function that syntactically mentions the TAIT by its path. This will still require looking at the body, but we don't need to typecheck the body, just do name resolution on it.
   • this option is just listed for completeness, it's the worst option :)

I am nominating this issue for T-lang to discuss which options they prefer.

[pnkfelix]

Discussing T-lang triage. We want/need to resolve choice between options provided asynchronously.

After we come to some conclusion, we'll FCP merge/close this to demarcate that conclusion.

[pnkfelix]

Here's the zulip thread the T-lang team will use to align on this: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/align.20on.20TAIT.20defining.20scope.20options.20lang-team.23107645/near/329277776

[nikomatsakis]

@rfcbot fcp merge

I propose that we accept #107809. It implements a conservative path forward. Basically any function that constraints a TAIT but doesn't list the TAIT in its arguments/return type is a hard error, giving us room to change the behavior in the future.

Final behavior as I understand it

• A TAIT has a defining scope that corresponds to the enclosing module or item.
• A defining use for a TAIT is any item that (a) is within the defining scope and (b) contains a function that lists the TAIT in the argument or return types, either before or after normalization (*see edge case below).
• Within the defining scope, an item is called constraining if it puts constraints on the value of the TAIT. i.e., for the item to type check, the hidden type of the TAIT must have a particular value. This could occur because of a let (e.g., let x: TAIT = 22_u32), a return (e.g., return 22_u32 in a function whose return type is TAIT), or in other ways.
• Any constraining item within the defining scope that is not a defining use is a hard error. This means we can later opt to allow such a use; or to allow it with an annotation of some kind; or to make other such changes.
• All defining uses must fully infer the hidden type of the TAIT and must infer the same type for the TAIT.
• WIthin the defining scope, TAITs must always be given generic arguments (e.g., fn foo<T>() -> TAIT<T> and not fn foo() -> TAIT<u32>). This ensures inference is tractable and well-defined.

Current bugs and limitations (forwards compatible to change)

• Within the defining scope, attempts to check whether TAIT implements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.
• A function that has an argument which is an associated type referencing a TAIT (e.g. <TAIT as SomeTrait>::SomeItem) ought to be considered a defining use. However, in the compiler today, if that associated type can be normalized, and the normalized form does not reference the TAIT, the function is not. This can only cause more errors.

[nikomatsakis]

@rfcbot fcp merge

I propose that we accept #107809. It implements a conservative path forward. Basically any function that constraints a TAIT but doesn't list the TAIT in its arguments/return type is a hard error, giving us room to change the behavior in the future.

Final behavior as I understand it

• A TAIT has a defining scope that corresponds to the enclosing module or item.
• A defining use for a TAIT is any item that (a) is within the defining scope and (b) contains a function that lists the TAIT in the argument or return types, either before or after normalization (*see edge case below).
• Within the defining scope, an item is called constraining if it puts constraints on the value of the TAIT. i.e., for the item to type check, the hidden type of the TAIT must have a particular value. This could occur because of a let (e.g., let x: TAIT = 22_u32), a return (e.g., return 22_u32 in a function whose return type is TAIT), or in other ways.
• Any constraining item within the defining scope that is not a defining use is a hard error. This means we can later opt to allow such a use; or to allow it with an annotation of some kind; or to make other such changes.
• All defining uses must fully infer the hidden type of the TAIT and must infer the same type for the TAIT.
• WIthin the defining scope, TAITs must always be given generic arguments (e.g., fn foo<T>() -> TAIT<T> and not fn foo() -> TAIT<u32>). This ensures inference is tractable and well-defined.

Current bugs and limitations (forwards compatible to change)

• Within the defining scope, attempts to check whether TAIT implements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.
• A function that has an argument which is an associated type referencing a TAIT (e.g. <TAIT as SomeTrait>::SomeItem) ought to be considered a defining use. However, in the compiler today, if that associated type can be normalized, and the normalized form does not reference the TAIT, the function is not. This can only cause more errors.

@rustbot labels -I-lang-nominated

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

Concerns:

• explicit-alternative (TAIT defining scope options #107645 (comment))
• why-not-just-the-return-type (TAIT defining scope options #107645 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.