https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198
Iain Buclaw <ibuclaw at gdcproject dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Witold Baryluk from comment #3)
> > 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();
> }
> ```
>
> I see, I guess you are right. I don't know how would one go to fix this to
> work correctly with existing linkers and not break other code.
>
> Thanks for clarifications.
To close this issue, I'll leave my thoughts on a similar topic that was touched
on the D ML (this time, regarding the linkage of inline functions).
I'm of the opinion that there is no concept of external (global) or internal
(local) linkage in D. Rather there's language linkage and module linkage.
Language linkage as in `extern(C++)`, `extern(C)`, `extern(Objective-C)`...
Module linkage as in for a given declaration resolves to the same symbol across
all TUs that import its residing module, but otherwise not strictly visible
outside of that.
It might do well to familiarize yourself with C++2a modules as a primer. But
even then, you'll have to unlearn a lot of things.
