Repository navigation
Private supertraits are not callable on concrete types #83882
Description
pub mod foo {
pub trait Foo: sealed::Bar {
fn foo(&self) {}
}
mod sealed {
pub trait Bar {
fn bar(&self) {}
}
}
impl Foo for u32 {}
impl sealed::Bar for u32 {}
}
fn meow_dyn(f: &dyn foo::Foo) {
f.foo();
f.bar();
}
fn meow_static(f: impl foo::Foo) {
f.foo();
f.bar();
}
fn meow_u32(f: u32) {
use foo::Foo;
// use crate::foo::sealed::Bar;
// ^ doesn't work because it is private
f.foo();
f.bar(); // Why does this error now?
}
fn main() {
meow_static(42);
meow_dyn(&42);
}error[E0599]: no method named `bar` found for type `u32` in the current scope
--> src/main.rs:30:7
|
30 | f.bar(); // Why does this error now?
| ^^^ method not found in `u32`
|
= help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
|
1 | use crate::foo::sealed::Bar;
|
I am reporting this because I believe this is a bug.
Both meow_dyn and meow_static type check, but calling .bar() on a concrete type is currently not possible. Is there a reason for that?
I would expect any of those two cases:
meow_u32should actually type check, and.bar()should be callable ifFoois visible, becauseBaris a supertrait.Barshould not be usable in any other context, because the trait is private.
I could not find any information about this in the reference.
Activity
eggyal commentedon Apr 6, 2021
#67105 seems related.
This is the solution proposed by rust-lang/rfcs#2845It strikes me that this is the correct solution, but I'm struggling to cite supporting evidence.
lcdr commentedon Apr 7, 2021
rust-lang/rfcs#2845 actually is only concerned with the case of a subtrait having an item with the same name as one in a supertrait (i.e. both
FooandBardefining abarmethod), and is unrelated here.The real issue here is that in generics/trait objects
Baris automatically brought into scope whenFoois used, even whenBarshould not be visible (and thus usable) in that context.eggyal commentedon Apr 7, 2021
Aye, that's why I had struck out that comment.☺️
steffahn commentedon Aug 8, 2021
This discussion on URLO today demonstrates a practical case of a public-in-private supertrait with methods that are (most likely) not intended to be exposed/callable. In my opinion, the fact that such methods are ever callable is surprising and unnecessary and should be considered a bug. We should try to detect the cases where a supertrait cannot be named through any public path (taking re-exports into consideration, etc) and exclude the methods in this case; I wouldn’t be surprised if such a change doesn’t even break any crates in practice.
cc @dtolnay to give a definitive answer on whether the methods on the “
Sealed” supertrait ofryu::Floatare supposed user-callable or not.