# Thoughts and tempering expectations on redefining structs

**URL:** <https://discourse.julialang.org/t/thoughts-and-tempering-expectations-on-redefining-structs/101190>\
**Category:** Internals & Design\
**Tags:** struct\
**Created:** [July 5, 2023, 12:11am UTC](https://discourse.julialang.org/t/thoughts-and-tempering-expectations-on-redefining-structs/101190 "2023-07-05T00:11:43Z")\
**Posts on this page:** 1\
**Showing post:** 36

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [July 9, 2023, 9:06pm UTC](https://discourse.julialang.org/t/thoughts-and-tempering-expectations-on-redefining-structs/101190/36 "2023-07-09T21:06:46Z")

</div>

> [@tim.holy](#):
>
> The compiler is allowed to make all sorts of decisions during codegen conditioned on the assumption that types are `const`, and there’s no equivalent of backedges documenting consequences of those decisions. Unless those get added, we can’t accurately perform invalidations if types change their definitions. And adding all those backedges would likely bloat the system enormously. That’s a pretty huge cost to pay for a little extra developer convenience.

I’m sure that’s naive, but even without backedges, couldn’t you iterate through the entire method table and invalidate all methodinstance (? maybe I’m using the wrong word) that accept an X or that are inferred to return an X?

> I think redefining structs is in a different category, most likely in the bucket “we don’t want to go there.”

💯 I can definitely understand that!

---

_[View the full topic](https://discourse.julialang.org/t/thoughts-and-tempering-expectations-on-redefining-structs/101190)._