-
-
Notifications
You must be signed in to change notification settings - Fork 15k
refining_impl_trait only fires on public traits #119535
Copy link
Copy link
Open
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.A-trait-systemArea: Trait systemArea: Trait systemF-refine`#![feature(refine)]`; RFC #3245`#![feature(refine)]`; RFC #3245F-return_position_impl_trait_in_trait`#![feature(return_position_impl_trait_in_trait)]``#![feature(return_position_impl_trait_in_trait)]`T-langRelevant to the language teamRelevant to the language team
Metadata
Metadata
Assignees
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.A-trait-systemArea: Trait systemArea: Trait systemF-refine`#![feature(refine)]`; RFC #3245`#![feature(refine)]`; RFC #3245F-return_position_impl_trait_in_trait`#![feature(return_position_impl_trait_in_trait)]``#![feature(return_position_impl_trait_in_trait)]`T-langRelevant to the language teamRelevant to the language team
Type
Fields
Give feedbackNo fields configured for issues without a type.
The
refining_impl_traitlint only fires for public traits. It does not fire without thepubkeyword in the code sample below:Difference from
async_fn_in_traitlintApparently 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 fnin traits, though, when there are some important distinctions:async fnlint is only temporary to help avoid footguns created by missing language features, and we want to make non-footgunny uses more convenient.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:
Later on, I want to write a test for
all_windows. But in order to do that, I have to change it to acceptimpl Application, which requires changing the output type toimpl Window + '_, and possibly changing all the users ofall_windowsas well. This can get unwieldy quick.We can say that the user should have used
impl Traitfrom 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