# Mutable/immutable struct fields **URL:** \ **Category:** Explain\ **Tags:** compiler\ **Created:** [July 7, 2024, 11:30pm UTC](https://ziggit.dev/t/mutable-immutable-struct-fields/5019 "2024-07-07T23:30:54Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![biosbob](https://ziggit.dev/user_avatar/ziggit.dev/biosbob/32/1987_2.png) [@biosbob](https://ziggit.dev/u/biosbob)\ **Post date:** [July 7, 2024, 11:30pm UTC](https://ziggit.dev/t/mutable-immutable-struct-fields/5019/1 "2024-07-07T23:30:54Z")
unlike container-level declarations (marked `const` or `var`), fields within a container don’t carry that distinction… and assuming these fields don’t appear within a `packed` or `extern` `struct`, my understanding is that the compiler is free to locate them in any order it thinks best… correct me if i’m wrong, but if my program effectively assigns a `comptime` known value to a field – and if it’s not modified subsequently – the field’s value is propogated like any other `const`… this field also appears to consume no runtime memory as well… since all fields are public, i generally rely on methods to actually initialize and/or update these fields – enforcing my semantics of what is really mutable versus immutable… assuming my clients don’t “cheat” and access fields directly (i’ll prefix field names with a leading “`_`” as a convention), is this pattern something i can more or less rely upon??? things seem to be working out (beyond my expectations were i coming from C)… i just want to increase my understanding of the compiler a bit more… ---
**Author:** ![AndrewCodeDev](https://ziggit.dev/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@AndrewCodeDev](https://ziggit.dev/u/AndrewCodeDev)\ **Post date:** [July 8, 2024, 12:42am UTC](https://ziggit.dev/t/mutable-immutable-struct-fields/5019/2 "2024-07-08T00:42:36Z")
Can you provide a scenario where you would be worried that it would fail? I think that would help us do some more direct detective work with ya. ---
**Author:** ![biosbob](https://ziggit.dev/user_avatar/ziggit.dev/biosbob/32/1987_2.png) [@biosbob](https://ziggit.dev/u/biosbob)\ **Post date:** [July 8, 2024, 1:30am UTC](https://ziggit.dev/t/mutable-immutable-struct-fields/5019/3 "2024-07-08T01:30:24Z")
it’s funny, because so far performance has exceeded my expectations!!! but here’s a very trivial snippet of my “immutuable field” idiom: ```zig const Thing = struct { _data: u8, pub fn getData(self: @This()) u8 { return self._data; } }; ``` if i then instantiate `Thing{ ._data = 10 }` statically, i consume _no_ additional `.data` space in the final image; and calls to `getData` on this instance fold away to the constant `10`… were i to have a `setData` method, the same initialized instance would consume some `.data` space… this technique appears to generalize, in that i can have some “readonly” properties and some “readwrite” properties by simply enforcing my semantics using getters and (optionally) setters… my most important concern is the “readonly” case – which again has worked famously for me… ---
**Author:** ![AndrewCodeDev](https://ziggit.dev/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@AndrewCodeDev](https://ziggit.dev/u/AndrewCodeDev)\ **Post date:** [July 8, 2024, 2:38am UTC](https://ziggit.dev/t/mutable-immutable-struct-fields/5019/4 "2024-07-08T02:38:17Z")
Yeah… tough call. I wonder if you’d run into the same issues that you’d get for referencing comptime var stuff though. I don’t know if the _order_ of things would be maintained… might be.