Wrapping C APIs in D functions of same name?

[Chris Nicholson-Sauls]

Rick Mann wrote:
> Tyler Knott Wrote:
> 
>> Yes.  Because module imports can be declared as "private" (and are by 
>> default), you can simply write two seperate modules.  One would contain 
>> all the extern (C) declarations, and the other containing the D 
>> wrappers.  The module with the wrappers would import the module with the 
>> externs (privately), and call the extern functions using the fully 
>> qualified name of them (e.g. in a module foo.bar with a function func 
>> taking (param), you'd call it as foo.bar.func(param)).
> 
> Of course; I should've thought of this.
> 
> I guess, though, there's no way to do it with a single module, right? 
> 
> Will the approach above result in link errors when I link my D program against the C library? Or does the D name mangling make the D symbol name different than the C name? Does the D-linkage mangling include the module name?

Exactly this.  A function 'int stuff(int)' in module 'bar' in package 'foo' will be 
mangled to something like: S20_D3foo3bar5stuffFiZi

Whereas the extern(C) function 'stuff' would simply be output as 'stuff' with no 
decoration.  Therefore, the two will not collide during linking.  However, this also means 
there is no reasonable way to distinguish the C and D functions from each other within 
source code aside from fully qualified names, hence using the second module to contain the 
extern declerations.

-- Chris Nicholson-Sauls