# Redefining structs without restart?

**URL:** <https://discourse.julialang.org/t/redefining-structs-without-restart/50826>\
**Category:** Internals & Design\
**Created:** [November 24, 2020, 5:08pm UTC](https://discourse.julialang.org/t/redefining-structs-without-restart/50826 "2020-11-24T17:08:10Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [November 24, 2020, 8:09pm UTC](https://discourse.julialang.org/t/redefining-structs-without-restart/50826/15 "2020-11-24T20:09:24Z")

</div>

> [@FedericoStra](#):
>
> Now, regarding structures, I imagine that every structure has a representation somewhere in the internals of Julia. When I do `struct S ... end` , something is allocated somewhere to keep track of this structure. What I’m suggesting is that if I execute `struct S ... end` again, then a new structure is created, which happens to have the same name (but is still a different entity internally). This is similar to what Python does:

I’ll just be so bold as to quote myself (though I’m fairly certain I’ve read something along those lines from other people as well 🤔)

> [@Objects whose structure can be redefined](https://discourse.julialang.org/t/objects-whose-structure-can-be-redefined/47733/4):
>
> The problem with redefining structs is that all existing code using that struct would have to be recompiled, as the new number of fields necessarily means a different memory layout as well. Doing this on-the-fly would mean potentially having to recompile the very code you’re running right now while it’s running, and since that’s not allowed, struct redefinition at runtime isn’t either.

To expand on that (and not make this shameless self promotion):

Julia has `eval` (and its macro companion, `@eval`), which evaluates an Expression at runtime in global scope. Now imagine the following:

```julia
struct IntWrapper
   a::Int
end

function increment(a::IntWrapper)
    a.a= + 1
end

function f()
    a = IntWrapper(1)

    # no wait, actually, I want IntWrapper to wrap Floats as well
    @eval struct IntWrapper
        a::Union{Int,Float64}
    end

    b = IntWrapper(5.0) # wait, which Constructor will be called now? And which type will `b.a` have?

   increment(a) # wait, do we print here as well..?
   increment(b)
end

```

Julia is a compiled language, not interpreted. This means that, when I call `f()`, the function `f` _as a whole_ is compiled to machine code. But I have `eval` code in there that changes the behaviour of the code afterwards while staying in the same function! That’s impossible, so it’s disallowed.

There are more details here, but that’s the gist of it. You could of course change all function calls to make a dynamic lookup in case the definition of the types or the function has changed… but then you lose all benefit of compiling functions in the first place and you’re back to interpreted speeds (which, I’m sure, you also don’t want).

It’s easy to say “why not just do x” and of course you _could_ do x, but that often comes at the cost of things we really want to have, like fast, native, compiled code that can run everywhere. If you insert dynamic lookups at any point that you call a function, writing e.g. GPU kernels is right out (without resorting to a second compiler). There are a lot of design decisions like this, and often there sadly isn’t a straightforward, compact answer why it is that way.

* * *

In any case, there have been _A LOT_ of topics on this forum about this and similar things already - you’re not the first to encounter them and won’t be the last. There’s also a lot of issues on the issue tracker, so please do a little more research before pointing to feature X from Y and ask why julia doesn’t do that and that it’ll be just so easy to do.

---

_[View the full topic](https://discourse.julialang.org/t/redefining-structs-without-restart/50826)._