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

Associated types lets you expose private types in public signatures (?) #22912

Closed
japaric opened this issue Feb 28, 2015 · 4 comments · Fixed by #22990
Closed

Associated types lets you expose private types in public signatures (?) #22912

japaric opened this issue Feb 28, 2015 · 4 comments · Fixed by #22990
Milestone

Comments

@japaric
Copy link
Member

japaric commented Feb 28, 2015

STR

#![crate_type = "lib"]

pub struct Public;
struct Private;

impl Iterator for Public {
    type Item = Private;

    fn next(&mut self) -> Option<Private> {  // OK(???) `Private` type in public method 
        unimplemented!();
    }
}

// an inherent method rejects the same pattern
impl Public {
    pub fn my_next(&mut self) -> Option<Private> {  //~ error: private type in exported type signature
        unimplemented!();
    }
}

pub trait MyIterator<Item> {
    fn next(&mut self) -> Option<Item>;
}

// the old version of `Iterator` doesn't allow returning `Private` from `next()` either
impl MyIterator<Private> for Public {  //~ error: private type in exported type signature
    fn next(&mut self) -> Option<Private> {
        unimplemented!();
    }
}

AFAIK, you can't put private types in "public" items (public as in marked with pub). Iterator::next is not explicitly marked with pub, but for all intent and purposes all the methods in a trait are public if the trait is public. So, I think the impl 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

rustc 1.0.0-nightly (e233987ce 2015-02-27) (built 2015-02-28)

cc @alexcrichton @nikomatsakis

@alexcrichton
Copy link
Member

I agree, I think this may have just been accidentally overlooked when implementing associated types.

@nikomatsakis
Copy link
Contributor

On Sat, Feb 28, 2015 at 10:59:14PM -0800, Alex Crichton wrote:

I agree, I think this may have just been accidentally overlooked when implementing associated types.

Yes, that. There was language in the RFC describing trait item signatures and how they should
be treated, and I think we just failed to extend that to associated types.
Definitely a bug.

@nikomatsakis
Copy link
Contributor

triage: P-backcompat-lang (1.0 beta)

@pnkfelix
Copy link
Member

pnkfelix commented Mar 2, 2015

Note also that #22261 is still open.

Manishearth added a commit to Manishearth/rust that referenced this issue Mar 3, 2015
 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
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

Successfully merging a pull request may close this issue.

5 participants