When translating C code to D, I sometimes come across a static function with a name that could easily clash if it weren't static:
```
static void terminate() {}
```
The closest equivalent D signature would be:
```
extern(C) private void terminate() {}
```
However, even with `private` the compiler intentionally emits a global `terminate` symbol to the object file (see Issue 7083). I could mark it extern(D) so it would get a mangled name that wouldn't clash, but that also changes the ABI. Considering static symbol support was added to dmd for ImportC (issue 22428), it might be worth exposing this to D code as well using something like `@Cstatic` or `pragma(noLinkerSymbol)`.
Comment #1 by bugzilla — 2022-03-05T05:54:04Z
The reason for D's behavior is that when doing metaprogramming, lots of symbols get generated, including private ones. When doing this across multiple files, the generated symbols are often identical, so D puts them in COMDAT sections and the linker merges them so only one appears in the executable.
With your suggestion, the symbols would not be merged, but would be duplicated and consuming executable file size.
This would be a significant change in behavior.
Because of this you suggest marking them differently so the names won't even appear in the object file, and so the linker never attempts to merge them.
This hasn't come up before, so I'd like to see a compelling use case to make a language change?
Comment #2 by dkorpel — 2022-03-05T10:01:54Z
(In reply to Walter Bright from comment #1)
> This would be a significant change in behavior.
I don't want to change templates or 'normal' extern(D) functions, it's only for niche -betterC purposes.
> This hasn't come up before, so I'd like to see a compelling use case to make
> a language change?
The use case is: I have a C to D translator, and it doesn't know what to do with `static` declarations. It translates to `private`, but that still results in symbol clashes sometimes (like a library defining a static function `terminate`, which was also defined in a Windows DLL IIRC).
It's not supposed to be a big language change, it could even be a compiler extension similar to LDC's `pragma(LDC_no_moduleinfo)` and `pragma(LDC_no_typeinfo)` (https://wiki.dlang.org/LDC-specific_language_changes), though I'd like all compilers to use the same syntax for it of course.
Comment #3 by robert.schadek — 2024-12-13T19:21:17Z