> 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".
