but why importc instead of exportc

because the type is being imported from C (and defined in a C library)

Yet you want it to occur in the produced C file so as far as the compiler is concerned you export it...

Yet you want it to occur in the produced C file so as far as the compiler is concerned you export it...

well, that doesn't seem logical - that would place the responsibility of defining the type on nim, which is not the intent. The type is defined in a C library - what nim is supposed to to is create an opaque struct to be used for pointers but whose definition remains unknown to the compilation unit - nothing else. In fact, this is also what happens, exportc tries to define the type which is a worse outcome:

typedef struct MyType MyType;
struct MyType {
	char dummy;
};

Hmm ok, I get what you're saying.

It seems that lots of codebases relies on importc implying nodecl. e.g. status-im/nim-stint#166

hm, that's an unfortunate mess - the manual seems pretty clear on the intent of nodecl / header here, in favor of the interpretation of this issue, so technically such code is buggy (as buggy as the compiler :) ).

stint at least is easy to fix since nodecl works with all nim versions as documented.

Well the issue is subtle, "this type comes from C but also generate it in the C code" ... it's no wonder why we never encountered it before.

it's no wonder why we never encountered it before.

I think it's mostly because most of the time, people tend to use header which implies nodecl which is why it doesn't come up..

In this particular case, there's actually no header involved, or rather the nim file is the header because the relevant c code is also being generated and it doesn't need a header file. I could generate a c header file just to please nim, but that seems wrong too.

I think the solution here is:

type MyType {.incompleteStruct.} = object

var v {.exportc.}: ptr MyType

It is incomplete so the codegen should produce the "forward only" struct tag thing and it needs to emit the type as it is not imported.

Of course this doesn't work with today's compiler, but this can be done without breaking anybody's code (fingers crossed).

I think the solution here is:

This will still apply name mangling to the type - in theory it shouldn't matter since the name ultimately is arbitrary inside the compilation unit unless compilers do some fancy type-based aliasing analysis on this name in LTO mode, ie across CUs. I have no idea if this is a real issue or not, but it's something to consider at least - it would also maybe matter if you have something like:

type MyType {.incompleteStruct.} = object

proc f(v: ptr MyType) {.importc, header: "myheader.h".}

here, nodecl is implied by header so it might be that MyType must match by C name as well in the declaration of f.

To influence the name mangling .extern: "myname" can be used:

type MyType {.incompleteStruct, extern: "MyType".} = object

var v {.exportc.}: ptr MyType