Ability to make struct members readonly when referenced from another namespace

Imagine a struct instance with fields that must stay internally consistent. Then it would be helpful to be able to mark these fields as "read only" when referenced outside their own "class/namespace/struct".

// status quo: 
const DelicateState = struct{
	x : u8,
	y : u8, // y must be 60% of z to closest integer - x/2 to closest integer
	z : u8, // z must always be double of x mod 256!
}

// want
const Delicate = struct{
  //"selfmut" marks a variable as mutable only within its own struct/namespace
	x : selfmut u8,
	y : selfmut u8,
	z : selfmut u8,
	
	fn modifyX(self: Delicate, x : u8){
		// set x
		// modify y and z so they are consistent
	}
	fn modifyY ....
	fn modifyZ ....
}

test "Delicate struct" {
	const dct = Delicate.init();
	dct.x = 43; // -> compile time error!
	
	dct.modifyX(43); // -> OK!
	_ = dct.x; // -> OK!
}

This feature is arguably just about helping developers discipline themselves. So it might be out of scope for a low-level oriented language like zig. Though at the same time, this kind of feature can be very helpful for maintainability in larger projects, if that is within zig's scope.

[hryx]

Related: #2059

Making fields read-only outside a package is an interesting alternative/compromise to fully private fields. I've considered it before but haven't experimented with actually using it yet. I'd recommend a more obvious qualifier such as readonly.

[daurnimator]

I've been meaning to propose something like this myself!
The http header module (#2263) would benefit from this.

I have two other ideas on how to achieve this:
(1) Interfaces. If you want to hide or "protect" implementation details, interfaces are golden.
(2) Comptime. Something like std.access.markSelfMutableOnly({.x, .y, .z}) within the struct in question. This could achieve something similar as a keyword would.

[andrewrk]

This is one of those things where zig is going to not provide a language feature that, admittedly, could be useful, but ultimately is unnecessary to accomplish zig's goals.

Typedef could be viable for this use case (#5132). See that issue for explanation of the syntax
and semantics.

const ProtectedStruct = typedef(OrigStruct, .Encapsulated{.mode = .FieldsReadOnly} );

test "encapsulated struct" {
   // auto coercion from base to typdef allowed in the context
   // of encapsulation, but casting is required in the other direction. 
   const ps : ProtectedStruct = OrigStruct.init(); 

   ps.field1 += 1; // compile error
   _ = ps.field1; // ok

}

Then you would set ProtectedStruct as the parameter type in function that wants to avoid setting
fields to invalid states, and cast to OrigStruct whenever full access is desired.

OrigStruct would stay blissfully ignorant about encapsulation.

This typedef feature would require the compiler to "consult" what typedef config is associated with
a variable (ZigValue) each time there's a member access operation to either reject or accept.

[nektro]

an optimization Zig could add if it had const/readonly fields is memoizing loads

on top of the DX safety benefits mentioned above, if for instance a scope repeatedly does x.y and y is annotated as a readonly field, then the compiler would be free to store x.y in a temporary once and then using it multiple times knowing that the author has provided the guarantee that the value wont change out from under it. it could also elide x.y.z in a case where y and z are both readonly fields on X and Y respectively