Syntactically reject equality predicates

[fmease]

View all comments

Background (History)

Equality predicates have been syntactically valid since PR #39158 / nightly-2017-02-02 / 1.16 (released 2017-03-16, 9 years ago), both forms that is: $ty = $ty and $ty == $ty. They're not registered as an unstable feature despite having a tracking issue (#20041). Naturally, they don't have a feature gate. Of course, we reject them post-expansion, so they are still semantically invalid.

Parser scaffolding for $ident = $ty was added in RUST-19391 (2014) which was then generalized to $ty = $ty in RUST-20002 (2014) and extended to additionally cover $ty == $ty in RUST-39158 (2017). As mentioned, the last PR also made them grammatical.

RUST-87471 (2021) attempted to start impl'ing typeck'ing but it was closed due to concerns: #87471 (comment) (already back in 2017 there were concerns: https://github.com/rust-lang/rust/pull/39158/changes#r97811244).

In 2022, T-lang discussed this feature during a meeting and raised concerns: #20041 (comment). However, they were inclined to accept a restricted form, namely T::AssocTy = $ty (T is a (self) ty param or a self ty alias) and <$ty as Trait>::AssocTy = $ty since that's trivial to support in HIR ty lowering (this is still accurate).

Change

This renders equality predicates $ty = $ty and $ty == $ty syntactically invalid again. On stable, they're merely semantically invalid. This is motivated by the fact that

1. their syntax isn't even decided upon
   1. should it be = or ==?
   2. should the LHS be syntactically restricted to (possibly qualified) paths (i.e., TypePath | QualifiedPathInType), only semantically or not at all?
      • "syntactically" could indeed make sense since we might want to generalize types to so-called terms here (i.e., Type | GenericArgsConst) for mGCA but we can't generalize $ty = $ty to $term = $term due to ambiguities ¹ that would require backtracking whereas $typepath = $term wouldn't have that problem
2. we might (decide to) never impl this feature
   • after all, implementation concerns were raised as early as 9 years ago which are still relevant today even with the next-gen trait solver on the horizon
3. the compiler + tools contain a bunch of code for dealing with these predicates
   • like lowering, name resolution, rustfmt and Clippy
   • that's entirely useless since they get unconditionally rejected anyway
   • this code doesn't need to exist (for now)

I've merely upgraded the semantic hard error to a syntactic hard error, I've intentionally not introduced an unstable feature under which equality predicates become legal.

That's because a hard error is easier to push through procedurally, it's an important first step (we can always turn it into a feature gate error later on) and since this potential feature isn't backed by any official lang experiment.

I don't consider T-lang's message #20041 (comment) from 2022 to be sufficient because it doesn't answer questions like (1.i), (1.ii) or whether code like T: Trait<A>, <T as Trait<B>>::AssocTy = Ty (A ≠ B) or T: Trait<'r>, for<'a> <T as Trait<'a>>::AssocTy = Ty should be legal (which would be more powerful / could lead to typechecking issues, idk) or not assuming we're going with the restricted form ofc (we would need input from T-types).

Lang nomination

#153513 (comment)

Footnotes

1. Code lile fn f() -> i32 where { 0 } is intentionally legal today but if we had $term = $term the { 0 } could then also be the start of an equality predicate like { 0 } = 0. ↩

[fmease]

@bors try

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3248bac (3248bace201b6227b0ff78eacc8b00d805551a86, parent: ff086354c9fc93e1da1d2f4d255456624fbcd099)

[fmease]

@craterbot check

[craterbot]

👌 Experiment pr-153513 created and queued.
🤖 Automatically detected try build 3248bac
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-153513 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-153513 is completed!
📊 6 regressed and 2 fixed (839795 total)
📊 2542 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Footnotes

1. re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-153513/retry-regressed-list.txt ↩

[fmease]

@craterbot run mode=check-only crates=https://crater-reports.s3.amazonaws.com/pr-153513/retry-regressed-list.txt p=1

[craterbot]

👌 Experiment pr-153513-1 created and queued.
🤖 Automatically detected try build 3248bac
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[tmandry]

Like Jack, I was skeptical because I thought this would make it harder to introduce these in the future. But since we don't have any macro matchers today that can match over a where clause / bound, it won't do that.

@rfcbot fcp merge lang

[rust-rfcbot]

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

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

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.

[traviscross]

Thanks @fmease for pushing this forward; thanks @jackh726 for looking into this.

@rfcbot reviewed

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

@rfcbot reviewed

[rust-rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[traviscross]

The Reference is already correct on this point.

cc @rust-lang/lang-docs @rust-lang/fls