Yeah if it's going to be added to the compiler then that's great. Those
workarounds don't work in my use case but I've just simplified things to remove
the case statement
> It looks like this isn't supposed to work and should be flagged by the
> compiler.
It's more like it was a use-case that was missed and should be added to the
compiler.
Current workarounds:
* Use `let` instead of const:
[https://github.com/status-im/nimbus/blob/bfd71130/nimbus/vm/interpre
Thanks @mratsim for pointing me to those issues! I did not find them before. It
looks like this isn't supposed to work and should be flagged by the compiler.
@shirleyquirk thank you for also looking into the issue. I had tried that but
with my object init proc it only works if the procedure is a
looking at the generated C code this is definitely a bug
when root is instantiated
_[both](https://forum.nim-lang.org/postActivity.xml#both) root.value and
root.children are initialized if root.value is set to 0 after root.children has
been set, it overwrites the seq pointer
which isn't great,
Known issue:
[https://github.com/nim-lang/Nim/issues/13081](https://github.com/nim-lang/Nim/issues/13081)
And linked:
*
[https://github.com/nim-lang/Nim/issues/8015](https://github.com/nim-lang/Nim/issues/8015)
*
[https://github.com/nim-lang/Nim/issues/8007](https://github.com/nim-lang/Nim
i don't know what's going on either, but swapping A and B:
Node = object
case kind: NodeKind
of B:
value: int
of A:
children: seq[Node]
Run
works
I'm getting some odd behavior that I don't understand. I've simplified it down
to this example:
type
NodeKind = enum A, B
Node = object
case kind: NodeKind
of A:
children: seq[Node]
of B:
value: int # < this line
