Unimplementable ("Sealed") Traits

[elichai]

Hi,
a lot of times you want to have a trait in your library/crate that can't be implemented by the library users.
either because it's a marker trait for FFI related things, related to a custom type system, or because it's very highly unsafe and weird.

libstd's solution to this problem is exposing pub traits but marking them unstable to implement i.e. https://doc.rust-lang.org/std/slice/trait.SliceIndex.html

I propose we add something like #[non_exhaustive] but for traits, i.e. #[unimplementable]
we can already see similiar weird tricks in the wild, i.e.
https://docs.rs/zerocopy/0.2.8/src/zerocopy/lib.rs.html#207
https://github.com/rust-bitcoin/rust-secp256k1/blob/master/src/context.rs#L10
and more.

[CryZe]

I think the general term for them is "sealed traits", so the attribute could be #[sealed].

Looks like there's even a Pre-RFC: https://internals.rust-lang.org/t/pre-rfc-sealed-traits/3108

[elichai]

Thanks. I guess this can be closed then.

EDIT: arghh, that thread got closed for no activity.

[elichai]

it seems like Niko wrote down most of my thoughts on the matter: https://internals.rust-lang.org/t/pre-rfc-sealed-traits/3108/11

[RustyYato]

@elichai note that you can't implement SliceIndex even on nightly. This is because std uses an approximation of sealed traits by giving SliceIndex an unnamable parent trait.

[elichai]

@elichai note that you can't implement SliceIndex even on nightly. This is because std uses an approximation of sealed traits by giving SliceIndex an unnamable parent trait.

Wait. can I use the same trick? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7b20e99544632bdb16900f36644a2126

[RustyYato]

@elichai yes you can

[elichai]

Awesome :). so I think this discussion is kinda moot

[AZMCode]

so I think this discussion is kinda moot

Not really, since this is becoming a hard error "in future"

The issue does mention a workaround to avoid this, but when the only solution is a workaround for a workaround which itself is the official solution one should really consider implementing this officially. Pave the cowpath sort of thing.

Additionallty, the use of this workaround means that the trait cannot de documented by rustdoc, which leads to documentation in sections where it shouldn't be.

Finally, this feature feels too fundamental, and the workaround^2 too difficult to read, at least to me.

There was a second pre-RFC for this idea, but it got closed...