# Call for testing: Restricting trait implementability and field mutability

DevFeed: [Call for testing: Restricting trait implementability and field mutability](<https://devfeed.tech/articles/call-for-testing-restricting-trait-implementability-and-field-mutability-15099.md>)

Original publisher: [Read original article](<https://blog.rust-lang.org/inside-rust/2026/08/10/call-for-testing-impl-and-mut-restrictions/>)

Author: Ryosuke Yamano

Published: 2026-08-10T00:00:00Z

Content type: article

Language: en

Sources: [Inside Rust Blog](<https://devfeed.tech/sources/inside-rust-blog.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [compiler](<https://devfeed.tech/tags/compiler.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [rust](<https://devfeed.tech/tags/rust.md>), [scope](<https://devfeed.tech/tags/scope.md>), [sealed](<https://devfeed.tech/tags/sealed.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

Rust RFC 3323, "Restrictions," is ready for testing on nightly Rust. It introduces impl_restriction for limiting where traits may be implemented and mut_restriction for limiting where fields may be mutated.

## Source excerpt

We are excited to announce that RFC 3323 "Restrictions" is ready for testing on nightly Rust. In this post, we will briefly describe the features. If you are already familiar with them, you can skip ahead to the How can I help? section. The RFC is split into two features: impl_restriction and mut_restriction. What is impl_restriction? The impl_restriction feature allows explicit restriction of the scope in which a trait may be implemented. For example, consider a trait Foo with a method that we want users to be able to call, while preventing downstream crates from providing their own implementations. With this feature, we can write: #![feature(impl_restriction)] pub impl(crate) trait Foo { fn method(); } impl Foo for usize { fn method() {} } The impl(crate) restriction prevents Foo from being implemented outside the current crate. As with pub, other paths can also be specified, such as impl(super) or impl(in path). Without this feature, this use case is typically handled using the sealed trait pattern, which is described in the Rust API Guidelines. In short, this pattern defines a public Sealed trait inside a private module and makes it a supertrait of Foo. Because downstream crates cannot name Sealed, they cannot implement Foo. pub trait Foo: private::Sealed { fn method(); } // Implement `Foo` for selected types. impl Foo for usize { fn method() {} } mod private { pub trait Sealed {} // Implement `Sealed` for those same types, but no others. impl Sealed for usize {} } However, this pattern requires defining an additional Sealed trait. The new impl_restriction feature provides a more direct and concise way to express the same restriction. The feature also allows the compiler to produce a more direct error message when an implementation is attempted outside the permitted scope. For example, the following code: #![feature(impl_restriction)] pub mod foo { pub mod bar { pub(crate) impl(super) trait Foo {} } // `Foo` may be implemented here. impl bar::Foo for i8 {} } //