> For my use case it is very important, that I can get all the sizes at compile > time
You may not be able to make all these things available at Nim-compile-time because they are not fully determined until the C (or whatever) backend compile is reached. For example, type foo object = bar: char baz: int will induce generation by Nim of some struct in the C backend. This creates a choice for the C of how to layout the struct - is it "1 byte packed next to 4 or 8 bytes" or rather is there a 3 or 7 byte gap between `bar` and `baz`. Many back ends will put in that 3 or 7 byte padding to have the int field be aligned which can result in faster generated assembly code on some CPUs. Almost all C compilers allow some kind of compiler directives like GCC's `__attribute__((__packed__))` or an analogue to kill all padding and let users control layout. For the C backend (but maybe not others..?) it may be possible for Nim to use those directives for all its structs to workaround the ambiguities of backend struct layout and resolve these to Nim-compile-time values. It is very debatable if that is desirable, though. It is definitely more complexity than just "binding" calls. That binding is really more delegation than resolution to a value. What the compiler currently does seems the right thing to me which is to delegate the complex/compound cases to the backend and "optimize" the cases for simple/non-composite types where it can reliably know the answer. For compound types, Nim can know these backend layout sensitive values are Nim- and backend-compile-time constants, just not what the values are to do fully resolved at compile-time calculations. So, a higher level question is if this resolution to a value known at Nim compile time is really a strict requirement for your purposes or if you can relax that to delegated backend work so the calculation can be done at "backend compile time".