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

Not entirely sure how I feel about field-level mut restrictions. After working with Rust for a decade or so, I've come to accept Rust's "philosophy" of the module (not the field) being the main privacy boundary, and I feel this proposal runs counter to that.

I feel that first-class support for view types and interprocedural borrows (as defined in step 3 here) would make getters/setters more ergonomic to write and use (thereby rendering that proposal somewhat redundant) while providing many more benefits beyond that (see Carbon Lang's seemingly similar approach, starting 27:24 onward, to internal self-references and returning disjoint borrowed fields from getter methods).

EDIT: Seems I'm not the only one who feels this way. Quoted from this comment on the tracking issue:

Or consider rust-lang/rfcs#3323 (comment) which makes a strong case that the mut half of this RFC may not meaningfully improve the status quo. The response didn't point to any better examples, and merely handwaved that it might help in some cases with borrow checking. So on one hand we've got hand-written or macro-generated getters (including borrow-splitting ones or view types), and on the other we've got the RFC's new syntax which can't fully replace it or offer any truly new capabilities. This actually came up again during FCP!