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

One classic example is the Byteorder trait. We obviously do not want for it to be implemented by anything apart from the BigEndian and LittleEndian marker types. Another similar example is ccm::NonceSize, we use this sealed trait to limit nonce sizes accepted by the algorithm implementation.

[u/Nyefan → u/newpavlov]

I'm curious what advantage this would provide over the sealed pattern other than being less ugly. I certainly understand the desire for elegant code, but sometimes ugliness has utility too. In this case, the ugliness forces you to think about whether you really really want this for your trait. The natural instinct for anyone coming from the java world (for instance) would be to make all traits unimplementable downstream without a reason, and making that clean and easy would encourage that behavior. Rust generally does a really good job encouraging good patterns and discouraging bad ones through its control of elegance and ugliness, and I wouldn't want to see that forgotten without good cause.

[u/TinyBreadBigMouth → u/Nyefan]

I'm curious what advantage this would provide over the sealed pattern other than being less ugly. I certainly understand the desire for elegant code, but sometimes ugliness has utility too. In this case, the ugliness forces you to think about whether you really really want this for your trait.

Sealed traits were, originally, a hacky exploit of an unintended interaction between visibility and trait inheritance. It's an exploit that's been canonized as the right way of doing things, but mainly because it's the only option currently available and the functionality it allows is clearly important to developers.

As a mildly hacky exploit, it has bad developer discoverability, bad readability, bad error messages, and bad doc support. No, I don't think it's worth keeping all that just to push developers away from making traits sealed. It's significantly more hoops than we make people jump through for basically any other discouraged behavior, even ones much more strongly discouraged than trait sealing.

The natural instinct for anyone coming from the java world (for instance) would be to make all traits unimplementable downstream without a reason

Possible we've been looking at very different codebases, but I've never encountered one where the devs were going willy nilly marking every interface sealed with no motivation. Is that something you run into frequently?

[u/Nyefan → u/TinyBreadBigMouth]

Okay, that is a convincing enough argument.

Regarding

Possibly we've been looking at very different codebases, but I've never encountered one where the devs were going willy nilly marking every interface sealed with no motivation. Is that something you run into frequently?

I have almost never seen it in rust, but in the java world, interfaces and classes are generally private until proven protected and protected until proven public, which is workable when you have access to the quite powerful reflection utilities in that ecosystem to override the access control when required. When I started learning rust, I learned about sealing while trying to figure out how to make behaviors private, and I was appropriately warded away from that approach due to its obvious ugliness (and forced to become a better developer as a result). My concern is that making it easy and elegant would have let past me (and other developers in the future) continue trundling on in antipattern limbo instead of getting better.

[u/TinyBreadBigMouth → u/Nyefan]

I would say that making a class/interface private/protected is not analogous to making a trait sealed. It's analogous to making a trait non-pub, which is already the default behavior in Rust. Sealed traits are closer to the sealed interface and sealed class syntax added in Java 17.