https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198
--- Comment #2 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Witold Baryluk from comment #0)
> ```
> module t1;
>
> extern(C)
> private final int f() {
> return 5;
> }
> pragma(msg, f.mangleof);
>
> ```
>
> `gdc -c t1.d -o t1.o` results in object with this symbols:
>
> 0000000000000000 D _D2t111__moduleRefZ
> 0000000000000000 D _D2t112__ModuleInfoZ
> U _d_dso_registry
> 0000000000000000 T f
> 0000000000000000 W gdc.dso_ctor
> 0000000000000000 W gdc.dso_dtor
> 0000000000000000 u gdc.dso_initialized
> 0000000000000000 u gdc.dso_slot
> 0000000000000016 t _GLOBAL__D_2t1
> 000000000000000b t _GLOBAL__I_2t1
> U _GLOBAL_OFFSET_TABLE_
> U __start_minfo
> U __stop_minfo
>
>
>
> Symbol, '0000000000000000 T f' should instead be '0000000000000000 t f'
>
> Additional when using optimizations, I would expect the f to not be emitted
> at all, but it is still there (unless compiler decides not to inline it or
> its address is not taken and passed around), even with `gdc -O3`.
>
> gcc for C does use LOCAL for static functions and variables in translation
> unit. Similarly probably for C++ symbols in anonymous namespaces.
>
There isn't really a notion of a translation unit in D, the minimal
encapsulation unit is a module.
There are a number of reasons why static in the C sense doesn't exist though.
The main example to demonstrate the current behaviour is correct would be the
following:
```
extern(C)
private final int f() {
return 5;
}
auto pubf()() {
return f();
}
```
In this module, 'f' is unused, but it can neither be local or discarded because
if another module instantiates 'pubf', you'll run into linker errors.
(In reply to Witold Baryluk from comment #1)
> BTW.
>
> Using:
>
> ```
> extern(C) private final static int f() { ... }
> ```
>
>
> doesn't change anything.
static has no effect on module-level declarations
(https://dlang.org/spec/attribute.html#static)
final has no effect on anything that isn't a virtual member function (and I'm
not sure it even makes sense to allow it otherwise).
private is a visibility/access attribute that only affects symbol name lookup
resolution (https://dlang.org/spec/attribute.html#visibility_attributes).
DECL_VISIBILITY could be set as a further hint for 'private', but that won't
remove the fact you'll still get multiple definition errors.
Note: dmd marks top-level functions as weak, a behaviour I have no intention of
replicating.
