Continued: Declarations of the same C struct conflict when imported

Timon Gehr timon.gehr at
Fri Sep 6 10:25:30 UTC 2019

On 06.09.19 01:19, György Andrasek wrote:
> Annoying, but alias can deal with it. The problem comes in actually 
> using them. Annotated for clarity:
> ```D
> int archive_read_next_header(archive_h.archive*, 
> archive_h.archive_entry**);
> const(char)* archive_entry_pathname_utf8(archive_entry_h.archive_entry*);
> ```
> (I'm guessing this is the correct place to report this since this is a 
> notable improvement from ldc 1.13, which didn't even understand 
> pointer-to-opaque.)

Actually, the correct place is (issues posted 
only here are likely to get forgotten because nobody tracks issues 
discussed on the forums).

> ---
> They told me to go away. :)
> ...

LDC is mostly a compiler backend effort. Updating the DMD frontend will 
usually update LDC quickly after.

> I'm not trying to redesign the language,

You actually are, but that's not a bad thing.

> it simply didn't occur to me 
> that this won't work or isn't a trivial oversight. (Android is dark and 
> full of terrors.)
> ...

Making this work requires changing the language non-trivially.

> I can't imagine how it makes the language better to disallow 
> cross-module C calls like this, given that the least ugly workaround is 
> `void *`.

It doesn't make the language any better, but the way this is phrased 
makes little sense. The current behavior requires no additional effort. 
`extern(C)` just doesn't affect symbol identity on the D side:

module a;
import std.stdio;
extern(C) struct S;
template test(alias x){ int test; }
import b;

void main(){
     writeln(test!S," ",test!(b.S)); // 2 3

module b;
extern(C) struct S;

So even though the two declarations of S would refer to the same type on 
the C side, this is not the case on the D side. The code above is just 
one example of code that needs to change behavior to support the feature 
you want.

More information about the Digitalmars-d mailing list