Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

bivariance means that arguments are completely unconstrained #3

Open
lcnr opened this issue May 9, 2023 · 2 comments
Open

bivariance means that arguments are completely unconstrained #3

lcnr opened this issue May 9, 2023 · 2 comments

Comments

@lcnr
Copy link
Owner

lcnr commented May 9, 2023

struct Foo<T: Trait<Assoc = U>, U>(T);

trait Trait {
    type Assoc;
}

impl Trait for for<'a> fn(&'a ()) {
    type Assoc = String;
}

impl Trait for fn(&'static ()) {
    type Assoc = [usize; 3];
}

fn use_covariance_of_t(x: Foo<for<'a> fn(&'a ()), String>) -> Foo<fn(&'static ()), [usize; 3]> {
    x
}
@theemathas
Copy link

theemathas commented Feb 20, 2024

This code now gives the following error on version 1.76.0 stable, which seems to indicate that the behavior is a bug:

warning: conflicting implementations of trait `Trait` for type `for<'a> fn(&'a ())`
  --> src/lib.rs:11:1
   |
7  | impl Trait for for<'a> fn(&'a ()) {
   | --------------------------------- first implementation here
...
11 | impl Trait for fn(&'static ()) {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `for<'a> fn(&'a ())`
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #56105 <https://github.com/rust-lang/rust/issues/56105>
   = note: this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details
   = note: `#[warn(coherence_leak_check)]` on by default

See #56105

@lcnr
Copy link
Owner Author

lcnr commented Feb 20, 2024

👋 we intend to actually intend to accept this pattern long-term, so this warning will get end up getting removed without causing this code to error. We recently weakened the warning in rust-lang/rust#120716 to "the behavior may change in a future release".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants