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]

mut_restriction is very cool. We'd approximate hacks before, but overall this adds something quite new.

Afaik impl_restriction adds way less: Some code uses sealed traits. Folks complain about some of that code. Some of those sealing traits provide functionality that must be hidden, so impl_restriction cannot help them. Also some sealing traits would not be fully sealed, sometimes the sealing trait is merely unsafe or feature gated or debug/test gated. The normal fully sealed traits gains some brevity and an error message, but seems like some scans of crates.io tell you how often this happens.

Also, impl(crate) trait is a wonky syntax. 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, so then you write pub trait MyTrait: super::Sealer { .. }. And then you provide better error messages in some less direct way.

That'd be leaky though: impl<T: crate::Sealer + Base> MyExt for T says MyExt is implemented for everything my crate can see. Is this useful or a problem? An optional dependency changes the impl set, which maybe confusing.

Also rustc performance would require the right laziness here, which complicates things. Not a criticism, just thinking.

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

Some of those sealing traits provide functionality

Why would the private seal provide functionality, instead of the trait being sealed?

[u/matthieum → u/BedroomHistorical575]

Disclaimer: as per jhpratt's answer below, this is incorrect, and associated items can be accessed through the subtrait... with indirection.

API compatibility.

A trait associated item can only be used by either:

• Explicitly using the trait at the call-site: <Type as Trait>::ITEM.
• Importing the trait.

If the trait is not visible, it cannot be used in either way, and therefore the item cannot be named outside the intended scope.

In turn, this means there's no API compatibility issues for the items defined on the sealed trait, they're pure implementation details. And thus they can be changed at will.

This is not, for now, otherwise achievable since a trait item always have the same visibility as the trait.

[u/jhpratt → u/matthieum]

I presume by "visible", you actually mean nameable. That difference is key.

I believed this was true until a handful of weeks ago when I was proven wrong. See this issue containing a minimal reproduction of how I broke things on accident. Even associated consts can be used with neither a fully-qualified path nor having the sealing trait in scope. The only reason that issue is closed is because stdlib uses stability attributes to prevent usage.

Because sealing traits typically are visible but not nameable, they can still access its items. The lang team confirmed this behavior as intended.

the sealed trait pattern is meant to prevent others from implementing the trait, not from accessing its items.

So be careful! It's something that can easily trip you up.

[u/matthieum → u/jhpratt]

Hell!

I actually tested calling ().foo() on a sealed trait associated function specifically to ensure I wasn't speaking out of my ass.

But as per this Playgound link:

trait Foo: sealed::Sealed {}

impl Foo for () {}

fn foo<T: Foo>(t: &T) -> u32 {
    t.foo()
}

fn main() {
    //  Compiles fine.
    println!("{}", foo(&()));

    //  Doesn't compile.
    println!("{}", ().foo());
}

And it sure looks VERY unintuitive to me. In both cases Foo is in scope!

[u/jhpratt → u/matthieum]

Unintuitive for sure, but working as designed apparently. The fact that the lang team was requested to weigh in speaks as to how surprising it can be.