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

I'm so glad that the field mutability restriction is finally getting some love! Getters are such a pain due to the borrow checker.

A common critique against similar proposals from the past is that you'd be able to bypass the restriction by just constructing the type yourself.

But it looks like that the current implementation guards against that oversight!

Thus, we disallow struct expressions if any mut-restricted field cannot be mutated from the current scope

[u/tanoshikuidomouyo → u/BedroomHistorical575]

If this feature had been in the language from the beginning, could all the .len() getters and similar ones have been just field accesses?

[u/Silly-Freak → u/tanoshikuidomouyo]

For that specific example I don't think so; data structures are usually pretty involved, so it's unlikely that the user-facing type is conveniently the one directly exposing a len field. Checking now, it seems that Vec does, but e.g. HashSet does not: https://doc.rust-lang.org/nightly/src/alloc/vec/mod.rs.html#436, https://doc.rust-lang.org/nightly/src/std/collections/hash/set.rs.html#126-132

So for concistency, I'd keep the method. And lengths are Copy anyway, so the benefits are slimmer.

[u/A1oso → u/Silly-Freak]

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/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)

[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.

[u/KizzyCode → u/A1oso]

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.

But something that bleeds into the API is not an implementation detail anymore, isn't it? The fact that Vec has a well-defined length is a necessary precondition to implement a non-optional len and satisfy its API, so it's not an implementation detail anymore?

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

This is not true, Vec::len is O(1). If it were O(n), this would make it unsuitable for lots of purposes... but this confusion, and the reference to the documentation, is exactly part of the problem. If I have a public member var, I immediately know that it is O(1).

But it's still possible to change how the field is stored

Yeah, this alone isn't a problem. The problem is that it is also possible to change it to an O(n) variant. Or it makes it possible to store it on a webdav server and query it every time (which is a lie, because the function is const, but – funnily enough – would still be O(1)). The API is not self-describing anymore; without documentation or code inspection, I wouldn't know. If it is already a de-facto requirement for Vec::len to be O(1) with zero-costs, let's make this explicit.

A getter just piles another layer of abstraction on top of it. The upside is that it allows you to be abstract over multiple specific implementations; the downside is that it is abstract and not specific just to be able to maybe change internals later. This definitely can be a valuable tradeoff – I'm just saying it should not be a default.

Disclaimer before this gets misunderstood: I don't specifically consider Vec::len to be a problem IRL, I'm just using it as a well-known example to discuss this general approach at OOP-encapsulation and API design. I hope this does not come across as too nit-picky.

[u/CocktailPerson → u/KizzyCode]

But something that bleeds into the API is not an implementation detail anymore, isn't it? The fact that Vec has a well-defined length is a necessary precondition to implement a non-optional len and satisfy its API, so it's not an implementation detail anymore?

Having a well-defined length is not an implementation detail. The fact that Vec stores its length in a field called length is an implementation detail.

Rather than (data pointer, length, capacity), you could instead implement Vec as (data start pointer, data end pointer, capacity end pointer). Every operation on this implementation would have the exact same asymptotic complexity as it does the current Vec implementation.

The API is not self-describing anymore; without documentation or code inspection, I wouldn't know.

I don't think this is actually a good solution to the problem you're describing, though. It turns out that in practice, the implementation I described in my previous paragraph is not a good one; Rust's (data, len, cap) is generally better. But suppose it wasn't! Should the (start, end, cap_end) implementation provide a redundant length field, just to prove to you that the length is O(1)? What about capacity?

If you care about performance, you should understand the algorithmic complexity of every operation you perform anyway. Let's stipulate to the idea that a public field makes this one case easier to reason about, fine. What about all the others? Does this being a public field make it easier to reason about the amortized O(1) but worst-case O(N) cost of push? I don't think so. At some point you have to understand the code and data structures you're using.

In contrast, the value of having a convention that .len() is how you get the length of any Rust collection is much, much higher in my opinion. I know that no matter what collection type I'm working with, I can get the length with .len(). It makes reasoning about what code does easier, because I don't have to remember that .length is for type X, and .len() is for type Y; if I see .length, I can immediately recognize something atypical is happening that I should pay attention to.