Allow trivial constraints to appear in where clauses

[sgrif]

Rendered

[Ixrec]

Making this not an error seems like a good idea to me, but I'd keep it around as a lint/warning, since we are talking about "nonsensical" code, and I assume there are also macros where it'd be considered a bug if a trivial where clause got generated.

[sgrif]

That's an excellent point. I'm not able to update right now, but I like the idea of having it be around as a lint. I'll update the text to go that direction when I have a chance, and leave whether the lint is enabled by default or not as an unresolved question

[ExpHP]

This limitation has been a thorn in my side at least once. To my memory, it is the lack of this feature which makes it impossible for macros like newtype_derive to automatically and correctly generate impls for pairings of owned/borrowed arguments like

impl Add<Foo>  for Foo  where  i8: Add< i8, Output=i8> { ... }
impl Add<&Foo> for Foo  where  i8: Add<&i8, Output=i8> { ... }
impl Add<Foo>  for &Foo where &i8: Add< i8, Output=i8> { ... }
impl Add<&Foo> for &Foo where &i8: Add<&i8, Output=i8> { ... }

---

To play devil's advocate, I do have to wonder if some crates may have popped up since 1.7 that rely on these errors as a form of static assertion about what traits are implemented (as the author was likely unaware that trivially true bounds were intended to produce compiler errors). Out of concern for this, I might lean towards "warn by default", since macros can easily disable the warnings in their output.

[aturon]

@sgrif Sorry for the lack of attention from the lang team. I've nominated to get it in front of people ahead of the impl period.

[nikomatsakis]

@rfcbot fcp merge

Discussed this in the @rust-lang/lang meeting. There are already many points in the language where we allow similar things, and we've been generally moving in the direciton of allowing unsatisfiable constraints (with a warning). I propose to merge.

[rfcbot]

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

• @aturon
• @cramertj
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

No concerns currently listed.

Once these reviewers reach consensus, 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!

See this document for info about what commands tagged team members can give me.

[rfcbot]

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

[rfcbot]

The final comment period is now complete.

[aturon]

This RFC has been merged!

Tracking issue

[nox]

The RFC doesn't mention what should happen for where clauses on structs and other type definitions.

struct Foo where i32: IntoIterator;

fn main() {
    Foo;
}