# \`@fieldParentPtr()\` is innocent; what is dangerous is modifying a local copy of a structure

**URL:** <https://ziggit.dev/t/fieldparentptr-is-innocent-what-is-dangerous-is-modifying-a-local-copy-of-a-structure/11764>\
**Category:** Explain\
**Tags:** language, standard-library\
**Created:** [August 29, 2025, 10:55pm UTC](https://ziggit.dev/t/fieldparentptr-is-innocent-what-is-dangerous-is-modifying-a-local-copy-of-a-structure/11764 "2025-08-29T22:55:27Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![npc1054657282](https://ziggit.dev/user_avatar/ziggit.dev/npc1054657282/32/5790_2.png) [@npc1054657282](https://ziggit.dev/u/npc1054657282)\
**Post date:** [September 3, 2025, 9:32pm UTC](https://ziggit.dev/t/fieldparentptr-is-innocent-what-is-dangerous-is-modifying-a-local-copy-of-a-structure/11764/6 "2025-09-03T21:32:32Z")

</div>

I must apologize for my assertion, as I’ve found that `const` isn’t always reliable. A value that might be modified by an API could very well be `const`.  
A typical example I’ve found so far is `ArenaAllocator` . Not all of its members are pointers—its state member contains an `end_index` , which is actually modified by the API `ArenaAllocator.allocator().alloc`. However, because this modification is hidden by `anyopaque` , this value, while actually mutable, can be defined as `const` by the user without receiving an error.

Due to the widespread use of `anyopaque` vtables, my assertion that using `const` to determine whether a value is reliably copyable is unfounded.

---

_[View the full topic](https://ziggit.dev/t/fieldparentptr-is-innocent-what-is-dangerous-is-modifying-a-local-copy-of-a-structure/11764)._