• Hipreme (24/24) Feb 22 2023 Given the following situation: I want to use an externally
• Walter Bright (1/1) Feb 22 2023 I do it by simply declaring the function with C linkage: extern(C)
• Richard (Rikki) Andrew Cattermole (7/7) Feb 22 2023 That works except now the name can conflict with other C libraries ext.
• Paul Backus (5/11) Feb 22 2023 I think the real question here is, why don't you want to do this
• Mathias LANG (4/17) Feb 23 2023 I agree, you shouldn't do that. But having `extern` symbols in a
• Dukc (8/13) Feb 23 2023 Yeah, we're supposed to define or generate a header module that

Hipreme <msnmancini hotmail.com> writes:

Given the following situation: I want to use an externally 
defined D symbol in my current library without adding it as a 
dependency.


- I don't want to use an import path to bind to a symbol in D 
because this would complicate even more my build system, we 
already do it from C by doing: `extern(C) void something();`


We already can bind to a C++ symbol within a namespace by doing:
`extern(C++, "some_namespace")`.

The same can't be said for D. We can't pass a module name which 
the function is being resided.


The practical example right now is that I have my own type 
conversion functions, located in `hip.util.conv`.

I wanted to use the symbol as:
```d
extern(D, "hip.util.conv") extern TO to(TO)(FROM);
```


Even in an untemplated format, that would help me: (like passing 
an optional symbol saying it is a template.
```d
extern(D, "hip.util.conv", to) extern string to(int);
```

I know this is not gonna happen right now but this has a lot of 
use cases and it currently underused because one would need to 
actually use a D mangler library.

Walter Bright <newshound2 digitalmars.com> writes:

I do it by simply declaring the function with C linkage: extern(C)

"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:

That works except now the name can conflict with other C libraries ext.
So you either make the name less desirable to use or add mangling extra.
Not great solutions.

I'm gonna add this to my list of things I need to consider for the 
export DIP, since its redesigning how symbols work, the main question I 
have right now is how generic this needs to be.

Not that I exactly agree that you should run into this particular issue.

Paul Backus <snarwin gmail.com> writes:

On Wednesday, 22 February 2023 at 19:26:40 UTC, Hipreme wrote:
 Given the following situation: I want to use an externally 
 defined D symbol in my current library without adding it as a 
 dependency.


 - I don't want to use an import path to bind to a symbol in D 
 because this would complicate even more my build system, we 
 already do it from C by doing: `extern(C) void something();`

I think the real question here is, why don't you want to do this 
using `import`? What's the actual root cause of this 
"complication" you refer to? Better to address that problem 
directly than to add a new language feature as a workaround.

Mathias LANG <geod24 gmail.com> writes:

On Wednesday, 22 February 2023 at 20:22:18 UTC, Paul Backus wrote:
 On Wednesday, 22 February 2023 at 19:26:40 UTC, Hipreme wrote:
 Given the following situation: I want to use an externally 
 defined D symbol in my current library without adding it as a 
 dependency.


 - I don't want to use an import path to bind to a symbol in D 
 because this would complicate even more my build system, we 
 already do it from C by doing: `extern(C) void something();`

 I think the real question here is, why don't you want to do 
 this using `import`? What's the actual root cause of this 
 "complication" you refer to? Better to address that problem 
 directly than to add a new language feature as a workaround.

I agree, you shouldn't do that. But having `extern` symbols in a 
module is currently useless. I had a fix for it but Walter 
rejected it: https://github.com/dlang/dmd/pull/12839

Dukc <ajieskola gmail.com> writes:

On Wednesday, 22 February 2023 at 19:26:40 UTC, Hipreme wrote:
 Even in an untemplated format, that would help me: (like 
 passing an optional symbol saying it is a template.
 ```d
 extern(D, "hip.util.conv", to) extern string to(int);
 ```

Yeah, we're supposed to define or generate a header module that 
has the same name as the real module. It can probably be also 
accomplished with some really ugly `pragma(mangle, "...")` 
trickery, but I agree that defining module names in `extern(D)` 
would be much nicer and sometimes a better solution than a header 
file for every linked-to source file. D ABI should be just as 
practical for separate compilation as C and C++ ABIs.