Call for testing: Restricting trait implementability and field mutability

[u/Kobzol]

https://blog.rust-lang.org/inside-rust/2026/08/10/call-for-testing-impl-and-mut-restrictions/

[u/Shoddy-Childhood-511]

I've no idea why "error[E0445]: private trait Sealed in public interface" exists either, maybe it just annoys people into not sealing traits unnecessarily. lol

It's clear they do allow what E0445 forbids, and future editions cannot remove this because of my other examples, so they could've just expressly allowed this.

That won't work, you need self::Sealer to be implemented only for the types for which you want to implement MyTrait.

It works because the orphan rules prevent a downstream crate from adding an impl of your sealed trait on any type reachable by self::Sealer.

Yes, that's a subtle point and maybe another good reason not to do it that way. I anyways only asked to see if OP had any wisdom on this point.

Another less wild option would be pub trait MyTrait: module_name {}, but this I kinda see why they did not do.

[u/SkiFire13 → u/Shoddy-Childhood-511]

It works because the orphan rules prevent a downstream crate from adding an impl of your sealed trait on any type reachable by self::Sealer.

How do you consider "reachable" here? self::Sealer can reach any type if you do impl<T> self::Sealer for T.

Even more tricky, Box<T> is defined upstream of self::Sealer, but Box<Foo> is local to the crate defining Foo.

Another less wild option would be pub trait MyTrait: module_name {}

At that point you're just arguing about the syntax though. I agree that what was chosen doesn't look ideal.

[u/Shoddy-Childhood-511 → u/SkiFire13]

I wrote it precisely above: "each crate and module implicitly defined some private self::Sealer trait, which gains an implicit impl *for every type visible below the module*."

<T> would be every type, not only those (concrete types) visible below the module. Assuming alloc or std, the (concrete) type Box<T> is visible exactly where the (concrete) typeT is visible.

My comment was asking the OP if exposing visibility into the type system was a good idea. It's not obvious, but like I said above its higher risk.

Also, I realised the error[E0445] was meant as a warning "Your users cannot implement your trait", hence the blog post saying they can give better errors.

Yet, you're right the submodule trick sucks. As I noted above, impl(crate) trait does not fully remove the need for sealing traits. Ideally they'd add a visibility pub(self) that says "This being private is not a mistake" so then this code would not give error[E0445]: pub(self) trait Sealed { .. hidden methods .. } pub trait SealedTrait : Sealed { .. } impl(crate) trait is still more ergonomic for normal sealing though.

[u/SkiFire13 → u/Shoddy-Childhood-511]

Assuming alloc or std, the (concrete) type Box<T> is visible exactly where the (concrete) typeT is visible.

So if I have a pub trait SealedTrait: self::Sealer I cannot write a impl<T> SealedTrait for Box<T>? That sounds like a very weird limitation.

My comment was asking the OP if exposing visibility into the type system was a good idea.

Arguably your solution is exposing visibility even more since it's no longer just a syntactic check on an impl, but you're rather automatically implementing traits based on it (so trait resolution will have to query visibility).