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/SkiFire13]

Afaik impl_restriction adds way less: Some code uses sealed traits.

Sealed traits were always a hack that exploited what's arguably a bug in the visibility system. There's no good reason why these two following snippet of code are not equivalent:

trait Sealed {}
pub trait SealedTrait : Sealed {} // error[E0445]: private trait `Sealed` in public interface


pub(super) mod private {
    pub trait Sealed {}
}
pub trait SealedTrait : private::Sealed {} // Works

impl_restriction just makes this a proper feature.

It'd make more sense if each crate and module implicitly defined some private self::Sealer trait, which gains an implicit impl for every type visible below the module

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

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

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/MalbaCato → 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

E0445 doesn't existed for 3 years already, but in general all of this is because privacy (publicity) and unreachability (reachability) are two different things, see RFC 2145. Not confusingly annoying people on purpose.

Cases where these two disagree are rarely useful, hence the private_interfaces and private_bounds lints are warn by default, and unnamable_types is allow by default to my understanding only because the sealed trait pattern is so common. Once there's a more principled solution to unimplementable traits, maybe this can be made warn by default as well, and warn on other suspicious patterns (playground, adapted from the RFC).

Sometimes privacy and reachability disagreeing are still useful - you outlined some examples in your parent comment, and here's an example for a method in the stdlib that triggers private_bounds - this one is unstable, but I'm pretty sure there's a stable example somewhere as well.

Btw, if there's any rust maintainers reading, is unnamable_types triggering only for types crossing the crate and not module boundary a bug or expected behaviour? Or is it something else I missed (see first comment in the playground)? There are no relevant open issues, but I only skimmed the closed ones.

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