Skip to content

Allow trivial constraints to appear in where clauses #2056

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged

Conversation

sgrif
Copy link
Contributor

@sgrif sgrif commented Jul 5, 2017

@aturon aturon added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jul 5, 2017
@Ixrec
Copy link
Contributor

Ixrec commented Jul 5, 2017

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
Copy link
Contributor Author

sgrif commented Jul 5, 2017

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
Copy link

ExpHP commented Jul 5, 2017

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
Copy link
Member

aturon commented Sep 6, 2017

@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
Copy link
Contributor

@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 rfcbot added the proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. label Jan 18, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented Jan 18, 2018

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

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
Copy link
Collaborator

rfcbot commented Jan 31, 2018

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

@rfcbot rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Jan 31, 2018
@rfcbot
Copy link
Collaborator

rfcbot commented Feb 10, 2018

The final comment period is now complete.

@aturon
Copy link
Member

aturon commented Feb 14, 2018

This RFC has been merged!

Tracking issue

@aturon aturon merged commit 6f82eb1 into rust-lang:master Feb 14, 2018
@nox
Copy link
Contributor

nox commented Feb 25, 2018

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;
}

@Centril Centril added A-traits Trait system related proposals & ideas A-typesystem Type system related proposals & ideas labels Nov 23, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-traits Trait system related proposals & ideas A-typesystem Type system related proposals & ideas final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants