rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.26k stars 12.71k forks source link

`refining_impl_trait` only fires on public traits #119535

Open tmandry opened 10 months ago

tmandry commented 10 months ago

The refining_impl_trait lint only fires for public traits. It does not fire without the pub keyword in the code sample below:

pub trait Foo {
//^ Required for lint to fire
    fn foo(self) -> impl Debug;
}

impl Foo for u32 {
    fn foo(self) -> String {
//                  ^^^^^^
//  warning: impl trait in impl method signature does not match trait method signature
        self.to_string()
    }
}

Difference from async_fn_in_trait lint

Apparently I was part of the discussion of this at one point (see also the zulip topic on this). I think it got lumped together with the discussion about the lint for async fn in traits, though, when there are some important distinctions:

The second point is important, because as a user I would expect such a fundamental mechanism to behave independently of whether the trait happens to be crate-public or not. This can lead to false expectations being created about the behavior in the other case.

Violating abstraction boundaries within a crate

As an example of the last point, let's say I as a user want to define a trait that my type implements ahead of actually generalizing my code:

trait Application {
    fn windows(&self) -> Vec<impl Window>;
}
trait Window {
    fn title(&self) -> Option<String>;
}

struct App;
struct Win;

impl Application for App {
    fn windows(&self) -> Vec<Win> { todo!() }
}
impl Window for Win {
    fn title(&self) -> Option<String> { todo!() }
}

fn all_windows(apps: &[App]) -> Vec<Win> {
    apps.iter().map(|a| a.windows()).flatten().collect()
}

Later on, I want to write a test for all_windows. But in order to do that, I have to change it to accept impl Application, which requires changing the output type to impl Window + '_, and possibly changing all the users of all_windows as well. This can get unwieldy quick.

We can say that the user should have used impl Trait from the beginning, but that might be inconvenient when prototyping. If they are leaning on traits to provide the outlines of an abstraction boundary, we should let them opt in before punching through said boundary, IMO.

cc @compiler-errors

traviscross commented 9 months ago

@rustbot labels -I-lang-nominated

We discussed this today in triage and developed a consensus to: