Presently there is no way that I can find to declare a D symbol in another module. That is, this doesn't work:
==========
module m1;
import some.type; // defines SomeType
extern(D) SomeType m2.var;
void foo()
{
m2.var.doSomething();
}
==========
The reason I want this is that I am generating D source code programmatically - a file full of tables. And I am using DMD's dependency reporting facility to generate build rules for use in a Makefile.
Because of the build rules, all of the source code has to be valid enough to satisfy DMD at all times. Including when the generated code files do not exist (after a make clean, for example).
That means that I cannot have an import of a file which does not exist, so I cannot simply do import generated.module;
D *does* have support for extern (C), and I could certainly use that. But that eliminates the benefit of namespacing in the first place.
What I would like is a way to provide a module definition that includes the declaration of an external D object. This way my code could import that module definition, and the build system would be happy. And the generated code could be generated, compiled, and added to the library later on, and the whole thing would work together and sing Kumbaya and live in peace and harmony, modulo the occasional lion attack.
Frustratingly, DMD already HAS this: the .di file. So that's what I'm using. It works pretty much exactly the way I want, except of course that I'm not generating the .di file from the .d source (which is itself a generated file).
Sadly, though, the spec says (http://www.digitalmars.com/d/2.0/dmd-linux.html#interface_files):
"""
D interface files bear some analogous similarities to C++ header files. But they are not required in the way that C++ header files are, and they are not part of the D language. They are a feature of the compiler, and serve only as an optimization of the build process.
"""
The important part being "they are not part of the D language."
I'm sure that I'm not the first, or even the second, person to think of generating data tables in source files. So I'm requesting either (1) what is the part-of-the-D-language way to do this; or (2) please add the .di mechanism, or something very much like it, to the D language proper.
Comment #1 by lt.infiltrator — 2015-11-01T02:41:18Z
Perhaps I'm misunderstanding what you're after, but isn't this what import does?
=======
module m1;
import m2 : var, doSomething;
void main() {
var.doSomething();
}
=======
module m2;
int var;
void doSomething(int a) { }
=======
Comment #2 by dmitry.olsh — 2018-05-22T09:14:23Z
I believe I've seen a general mechanism for that such as __ident("any string " ~ "expressions") that would also work beautifully.
Comment #3 by dlang-bot — 2021-07-08T12:10:54Z
@Geod24 created dlang/dmd pull request #12839 "Fix 5309 - Support `extern(D)` symbol refs" fixing this issue:
- Fix 5309 - Support `extern(D)` symbol refs
Currently, `extern(D)` is quite incomplete: An `extern(D)` symbol is mangled
as if it was in the module it is declared in, while users usually want to
declare a function or type that lives in another module.
Borrowing from the syntax that was adopted for `extern(C++, name.space)`, we introduce `extern(D, pkg.mod)`.
Note that, unlike `extern(C++)`, no string alternative is needed:
the motivation for the string variant was that C++ namespaces could be D keywords,
hence some namespaces could not be bound with the identifier variant,
a problem which obviously does not apply to `extern(D)` symbols.
The need for this functionality is easily demonstrated by druntime's `externDFunc`.
`core.internal.traits : externDFunc` is a template that defines an `extern(D)` symbol in another module.
This is currently done by using `pragma(mangle)` along with `core.demangle : mangleFunc`.
And as it turns out, the only reason for `core.demangle : mangleFunc` to exists is for `externDFunc`.
Hence, implementing this functionality will greatly simplify a core piece of druntime:
`core.demangle : mangle` (and its derivatives, including `mangleFunc` and `externDFunc`) can be removed
and replaced by `XXX.mangleof`, relying on the compiler instead of a library function which have to be
kept in sync with the compiler implementation.
https://github.com/dlang/dmd/pull/12839
Comment #4 by robert.schadek — 2024-12-13T17:54:27Z