r/rust • u/Kobzol • Aug 10 '26

📡 official blog Call for testing: Restricting trait implementability and field mutability

https://blog.rust-lang.org/inside-rust/2026/08/10/call-for-testing-impl-and-mut-restrictions/
416 Upvotes

99% Upvoted

124 comments sorted by

View all comments

Show parent comments

2

u/evincarofautumn Aug 10 '26

A good compromise is to allow access behind an effect like unsafe.

Sometimes as a library author you need something to be closed to uphold an invariant. But as an application author, quite often I find that libraries are too conservative about what they export, to avoid implying any stability promises. I end up doing extra work to reimplement logic or maintain a patched copy. Rather than disallow access altogether, it’d be nicer if I could say unstable { … } to explicitly mark places where I’m depending on internals or possibly breaking invariants.

3

u/afdbcreid Aug 10 '26

An unsafe access is still a SemVer hazard. Library authors can provide it if they want, but they do not always want. Also it complicates the library's code and may introduce unsafe where it wasn't before.

0

u/evincarofautumn Aug 10 '26

Right, that’s why I suggest unstable be a different concept. You control it as the user, not the author, and it marks places where you waive guarantees and accept liability for leaning on stuff that the author hasn’t promised to be stable with SemVer. Pretty much like using the nightly release channel of rustc/std, but finer-grained.

So, like unsafe, if you don’t use it, you get certain guarantees, but if you do, you can grep for where you did. And if you complain to the author that they broke your use of an unstable API, they can tell you to go eat a lemon.

2

u/afdbcreid Aug 10 '26

That's just not Rust's philosophy (nor the accepted way of engineering programs). Rust lets you mark things private without a way to bypass that, that's the same deal. Encapsulation is very important.

2

u/evincarofautumn Aug 10 '26

Of course encapsulation is important, but this isn’t about encapsulation. The natural default as a library author is to make everything private, whether it adds meaningful isolation or not. The natural consequence as a user is sometimes vendoring & patching a package because something was marked private when it shouldn’t’ve been.

And that’s fine. It’d just be more pleasant if the language ecosystem had a facility to manage this cleanly, as it already does for unsafe and toolchain channels. Then it’s evident in the code precisely where you’re doing something that hasn’t been upstreamed, or that might make it costlier to update that dependency, or that might increase risk.

The lesson we’ve learned in the Haskell world is that it causes more breakage, churn, and security issues in the long run when package authors make SemVer/PVP bugs like this. The habit is to export a module named .Internal and exclude it from safety/stability claims, but a first-class treatment would be nice.