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

RFC: Private trait items #52

Closed
wants to merge 1 commit into from
Closed

RFC: Private trait items #52

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Apr 24, 2014

No description provided.

@pnkfelix
Copy link
Member

pnkfelix commented Jun 5, 2014

team decided this sounds like a fine idea, but we do not want to attempt to do it for 1.0 (and it is not necessary to do it for 1.0).

Closing and Marking as Postponed.

@ghost
Copy link
Author

ghost commented Sep 4, 2014

If this gets implemented post 1.0, then we'll have to reintroduce the keyword priv which I think would be a shame. I think a lot better would be to require all trait items (i.e. methods, associated methods, associated types etc.) to be marked as pub for now. Later, like post 1.0, we could allow trait items to be declared without the pub keyword, which would make them private.

@erickt
Copy link

erickt commented Sep 4, 2014

@tommit: that sounds reasonable to me. I always thought it was a little odd I didn't have to mark trait methods as being public, but I did on impl Foo implementations. Want to write up a RFC for that?

@ghost
Copy link
Author

ghost commented Sep 4, 2014

@erickt: OK, I created one. RFC #227

@Restioson
Copy link

Restioson commented Jan 3, 2018

Recently, I've run into two cases where I've wanted to use private trait items in the last month or two.

Example 1

I found myself wanting to provide a helper method that should be implemented by the trait
implementor but not visible to anything but the trait's other methods.

Gist

Here, I wanted to have a write_raw helper method that write would call, so that every single
impl of Terminal wouldn't have to implement the boilerplate logic itself.

Workaround

In this case, I just gave up and made it public, adding a warning. This is sub-optimal, IMO.

Example 2

In a very similar situation, I found myself wanting to provide a helper method for a trait's methods,
but not make it visible to anything.

Gist

Here, I wanted to have a command helper function that would send a raw command code to a PS/2 device,
which would be unsafe (not Rust-wise) to expose as someone could send an invalid command, so it needs
to be private.

Workaround

In this case, I made command into a private, free-floating method taking &Device instead of &self,
however this is sub-optimal -- it would be so much nicer to use &self here instead of just taking the
trait by reference like you would in C perhaps (from what little I've seen of C).

With those in mind, I advocate adding private trait items to Rust, perhaps in the form of pub(impl) as mentioned in #275.


PS: I wasn't sure where to put this, so please correct me if this is the wrong place :)

@Centril Centril added A-traits Trait system related proposals & ideas A-typesystem Type system related proposals & ideas A-privacy Privacy related proposals & ideas labels Nov 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-privacy Privacy related proposals & ideas A-traits Trait system related proposals & ideas A-typesystem Type system related proposals & ideas postponed RFCs that have been postponed and may be revisited at a later time.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants