[rlp]

I'm a big fan of Nim, but I really wish it supported cyclic type declarations in separate files and out-of-order functions without forward declarations. As it is, I'm constantly structuring things around those limitations. Big projects often end up squeezed into a single huge file (or a few huge files).

[jblindsay]

You can re-order functions by using the {.experimental: "codeReordering".} pragma now.

[beagle3]

consider `include` instead of `import` if you want to break things down to smaller files.

Also, I'm with Araq on this one -- in my experience, every time I reached for a cyclic-cross-file-type-declaration, there was a much simpler acyclic solution I found later.

[rlp]

Include doesn't work for cyclic types, they need to be in the same "type" block. I do not agree with Araq's stance here, there are often cases when closely-related types need to reference each other, and it's not always convenient to put them in the same file. That's why you see the "types.nim" file in larger Nim projects -- no one has a good solution and just shoves them all together. And, if you use types.nim, you no longer have proper visibility control, since fields cannot be private and there is no package-level visibility. Most languages understand this, C/C++/Rust all allow at least the ability to forward declare a type (and Rust allows cyclic, out-of-order types).

[rishav_sharan]

yes please!

I had forgotten how irritating creating header like declaration files were till I tried Nim.