Hacker News new | ask | show | jobs
by erickt 2141 days ago
> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into.

Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works:

https://rust-lang.github.io/api-guidelines/future-proofing.h...
1 comments
jmillikin 2141 days ago
I'm aware of that workaround and do use it in `rust-fuse`[0], but I'm not satisfied for two reasons:

* It's not understood by rustdoc, so I have to manually document that the trait is sealed.

* It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality.

[0] https://github.com/jmillikin/rust-fuse/blob/a6ad16d1127d36f8...

link
eddyb 2141 days ago
> * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality.

It's public though, just not externally reachable, the private module doesn't make the trait private.

For example, if you wanted to, you could reexport the trait in the parent module (and I guess the drawback with the "sealed" pattern is accidentally doing that when it would be unsound do because of how you relied on it being "sealed", in unsafe code).

I don't think I've heard anything about plans to restrict anything based on reachability, and it would be massively backwards-incompatible so I doubt it would even be considered for an edition.

link
oconnor663 2141 days ago
> a future version of rustc might deprecate or remove that functionality

Are you sure about this? My understanding is that stable Rust limits itself to compatibility breaks that are both rare and trivially worked around. (Like adding a new inherent method to a standard type that happens to have the same name as your trait method.) Even in a new edition, I think there's a very heavy leaning towards changes that can be automated by `cargo fix`. Removing this idiom seems like it would be much too big of a change. (The obvious automatic fix -- just inserting `pub` as needed -- would presumably make a bunch of currently safe APIs unsound.)

link
swsieber 2141 days ago
I could see it being deprecated with an edition transition and a blessed solution.
link