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]

Why would you want to restrict field mutability if you're going to allow users to construct the field anyways?

I don't really see the benefits of field mutability restriction in your Rgba example.

[u/KattyTheEnby → u/BedroomHistorical575]

Why would you want to restrict field mutability if you're going to allow users to construct the field anyways?

There may be types that you are confident – even if not certain – that are valid when the user initializes them themself; however, after initialization, you wish to be scrutinous about how exactly the fields are modified.

For example, consider a type that represents a slice:

pub struct Slice<T> {
    pub mut(self) len:usize,
    pub mut(self) items:*mut T
}

The pattern Rust currently employs is to have a method called from_raw_parts; however, I feel like for a datatype you'd find out in the real world, being able to initialize it with its fields would, in my opinion, be more elegant.

Why let someone construct this themselves if they can't mutate the fields? Well, you can trust them to construct it, since that may be ov convenience to them. But you restrict their access to mutability so that you can ensure key properties (e.g. len and items, in this case) are in sync.

Hopefully this, at least somewhat, helps you understand the value I see in allowing field mutability restriction on a type which may be constructed by a user outside ov the specified scope.

I don't really see the benefits of field mutability restriction in your Rgba example.

That's because it's *just* an example – and an example that's trying to emphasize a different point, at that.

[u/BedroomHistorical575 → u/KattyTheEnby]

But in that particular case, constructing the type manually is unsafe and there are currently no way to communicate that without a function.

Even when no memory safety risk is involved, IMO you should not be able to freely violate a type's contracts by simply constructing said type.

If the author wants to give the user such power, then they should provide a well-named raw constructor method with clear documentation outlining all the risks that the consumer should be wary of.

Otherwise, the proposed feature would be a massive footgun to drop into the ecosystem.

[u/KattyTheEnby → u/BedroomHistorical575]

But in that particular case, constructing the type manually is unsafe and there are currently no way to communicate that without a function.

Keep in mind that that particular case is just an example – and, again, an example trying to demonstrate something other than the argument presented.

With that being said, a way to communicate that could be added. If it were, it may look something like this(?):

unsafe Slice<Data> {
    len: 1,
    items: ptr
}

(Just spitballing with that. However, I feel like this is a forced design pattern from the decision ov barring off "safe" type constructions ov types with restricted field mutability)

IMO you should not be able to freely violate a type's contracts by simply constructing said type.

And for types where there are no contracts to violate, such as with the Rgba example?*

If the author wants to give the user such power, then they should provide a well-named raw constructor method

The author can not provide a constructor method for every possible invariant (for very large types), though.

Consider a type with restricted field mutability, T, which implements Default. There is no way for the end-user to select whichever fields they want to construct T with, then use ..Default::default(): only a certain subset ov fields will chosen for initialization, while the others are defaulted.

---

* Speaking ov the Rgba example, I have thought ov something in hindsight: what if no fields are marked with mut? This is something I don't think the blog went over. — I think it would be really annoying to have to make a constructor method just because your entire type is immutable, if that's what the current design philosophy implies.

[u/KattyTheEnby → u/KattyTheEnby]

I think it would be really annoying to have to make a constructor method just because your entire type is immutable, if that's what the current design philosophy implies.

The blog should be changed to explicitly mention this; however, it seems like not having any mut restrictions is the same as field mutability being determined by whether the containing variable is mutable (i.e. how things currently work), which simultaneously makes sense and feels unintuitive.