About --header

[iacore]

nim c --nimcache:out --header:foo.h foo.nim will generate a header file at out/foo.h. It's not documented.

Is this flag supported?

The current output quality is not good. See this simple example I originally made for nim.

[saem]

We're moving away from transpiling and instead treat c, js, vm as purely targets. Unless there is a c source/bootstrap reason we should drop this capability.

---

In the example code you discovered seq[int] is opaque and honestly that's how things should be otherwise folks will start relying on the shapes we emit. It all seems fine but it eventually leads to need to know both languages and that's just not our design goal.

[iacore]

The header file is useful when using Nim functions in C, and other languages.

Letting Nim emit the header makes it less error prone to do that. Otherwise I need to write a custom header myself.

I think we should have fixed ABI for slice of something. openArray[T] seems to represent that, but it's not really a C type in codegen.

Basically I need proc foo(): openArray[T] or similar. Of course I can write my own type, but I think it's useful to have fixed ABI for all primitive types.

[saem]

That's not a use case we're targeting, especially not without someone invested in driving the necessary improvements to make it happen. By that I mean it's not a goal we would directly pursue, but one that may come about because the design/implementation of the language, and subsequent code generation, solidified in some useful pattern(s). Ones that could have an ABI fashioned around.

[iacore]

I think we should at lease have convert procs in nimbase.h, so it's easy to get data from Nim.

The JS backend need to generate ES Module, otherwise it's hard to use it with the JS ecosystem.

[saem]

I'm not so strongly opposed to such that we don't allow for it, I think the thrust of my point is that push come to shove if we have to choose between improving the compiler and keeping compatability, I'd break compatabililty without hesitation.

I expect that over time this wouldn't be an issue as core parts like this have a tendency to solidify/stabilize (lots of incoming dependencies).