[jmillikin]

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...

[eddyb]

> * 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.

[oconnor663]

> 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.)

[swsieber]

I could see it being deprecated with an edition transition and a blessed solution.