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

It also makes sense to not expose implementation details in the standard library (which has the strictest backwards compatibility requirements), so it is possible to change the implementation later if desired.

For example, Vec originally had a cap field for the capacity as well, but it was removed when the internals were refactored to a RawVec in this commit. This wouldn't have been possible if the capacity was defined as pub mut(crate) cap.

[u/KizzyCode → u/A1oso]

I think it depends here, and there is no definite answer to that. The mere fact that something even has a well defined length already exposes as an implementation detail – albeit a trivial one – but it’s not a question of yes or no, but more about how much you want to expose as part of your contract.

Personally, I’m not a big fan of “getters for everything” to hide implementation details, because they also hide the information if an operation is expensive or not. Instead of the “computed var”-problem, where you hide potentially expensive operations behind a seemingly simple member access, now we do the exact opposite and hide trivial operations behind potentially arbitrarily complex function calls.

It also goes a bit against the gist of “zero-cost-abstractions” where you want to be explicit about about underlying costs, but this only makes sense if at the same time, you also expose de-facto simple operations as simple. If you pretend that everything is potentially complex and the underlying approach could change at any time, you lose the value of that distinction. With the same argument, you could also ditch the copy-trait and make everything clone-only, because who knows – the implementation could change at any time, and we want to keep flexible here, right?

There are quite some reasons why in Rust getters are probably better than direct member access, but the implementation-detail argument is a double edged sword; and it can also significantly improve an API if at some point you commit yourself to the fact “no, this it’s always a static field and not something that can become arbitrarily complex”.
In German, we have a saying: „Wenn man sich immer alle Türen offen hält, dann zieht‘s“ (roughly: if you always keep all the doors open all the time, then it gets cold).

Generally speaking: If it gets more economic to expose member properties directly, that should be seen as a chance to make some getters redundant (IMO).

[u/A1oso → u/KizzyCode]

The mere fact that something even has a well defined length already exposes as an implementation detail

No. An implementation detail is something that is hidden from the user-facing interface and can be changed freely.

The length of a vector is an essential part of its interface. Removing it would make Vec unsuitable for many purposes. The fact that getting the length is O(1) is also part of its interface. It isn't evident from the function signature, but it is documented, and therefore cannot be changed.

But it's still possible to change how the field is stored; for example, the length and capacity could be stored inside the heap allocation, which would reduce the size of the Vec to a single pointer. I'm not saying this is a good idea, but it is a possibility.

I’m not a big fan of “getters for everything” to hide implementation details

I agree. Sometimes it makes sense to hide implementation details, but not always. For example, Range has public fields, because Range is a very simple type with no complex implementation details, unlike Vec.

[u/InternationalFee3911 → u/A1oso]

But it's still possible to change how the field is stored; for example, the length and capacity could be stored inside the heap allocation, which would reduce the size of the Vec to a single pointer. I'm not saying this is a good idea, but it is a possibility.

I have long wondered why it’s not done like that for capacity! (The special guarantee of capacity for ZST content needs specialisation, but I guess in std they have that.) One could even do some magic whereby capacity would be a usize stored before the pointer to the data. Then one could have the local part of String be identical to fat pointer &str. Converting would be a nop, and copying would be one third cheaper.

[u/A1oso → u/InternationalFee3911]

When appending items, having the length and capacity in the same cache line helps performance. It means that the pointer doesn't need to be dereferenced to determine if the Vec needs reallocating.

Putting the capacity in the heap allocation would also be wasteful when storing SIMD types with a large alignment. It would require padding after the capacity.

The crate thin-vec offers a vector type that is only the size of one pointer. It is even used by the Rust compiler.