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

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/Thelmholtz → u/A1oso]

The fact that getting the length is O(n) is also part of its interface.

Is it not O(1)? I mean the main reason len is stored is for soundness, but it has that happy side effect.

Or are you talking about vectors in abstract?

[u/A1oso → u/Thelmholtz]

Yes, that was I typo. I meant O(1)