-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Associated types lets you expose private types in public signatures (?) #22912
Comments
I agree, I think this may have just been accidentally overlooked when implementing associated types. |
On Sat, Feb 28, 2015 at 10:59:14PM -0800, Alex Crichton wrote:
Yes, that. There was language in the RFC describing trait item signatures and how they should |
triage: P-backcompat-lang (1.0 beta) |
Note also that #22261 is still open. |
Associated types are now treated as part of the public API by the privacy checker. If you were exposing a private type in your public API via an associated type, make that type public: ``` diff pub struct PublicType { .. } - struct Struct { .. } + pub struct Struct { .. } pub trait PublicTrait { type Output; fn foo(&self) -> Self::Output; } impl PublicTrait for PublicType { type Output = Struct; fn foo(&self) -> Struct { // `Struct` is part of the public API, it must be marked as `pub`lic .. } } ``` [breaking-change] --- r? @nikomatsakis closes rust-lang#22912
STR
AFAIK, you can't put private types in "public" items (public as in marked with
pub
).Iterator::next
is not explicitly marked withpub
, but for all intent and purposes all the methods in a trait are public if the trait is public. So, I think theimpl Iterator for Public { type Item = Private; .. }
should be rejected by the privacy checker. (Or, I could be wrong and this is "correct" behavior - and this wouldn't be the first time that the privacy/module system allows things that I find unreasonable)Version
cc @alexcrichton @nikomatsakis
The text was updated successfully, but these errors were encountered: