Why extern variables and functions within template/struct/class have a D mangling

[Dicebot]

On Wednesday, 8 May 2013 at 10:28:40 UTC, Andrej Mitrovic wrote:
> I suppose the ideal situation would be to have extern(C) follow 
> strict
> C mangling and calling convention (meaning no mangling for 
> nested
> extern(C) symbols), and have a separate linkage(C) feature to 
> be used
> when we want to set the linkage of a symbol (well, it's 
> probably only
> useful for functions) but let the compiler mangle it any way it 
> wants
> to (to avoid any symbol clashes).
>
> There's a pull request somewhere which enables setting custom 
> mangle
> names for symbols, so we'll at least have the flexibility in 
> picking
> symbol names that we need.

That may work as temporarily solution but I really think it is 
just hiding forest behind the trees. That part of language needs 
some serious attention at one point, not just few pull requests. 
To define all possible linkage modifiers. To define possible 
mangling modifiers. To define symbol visibility.

For example, do you remember discussion about classes and 
provable method (non-)virtuality? Which ended at a conclusion 
that it can't work because class can be   inherited from 
anywhere, for example from called dll. Funny thing we have an 
"export" as a protection attribute: "Export means that any code 
outside the executable can access the member. Export is analogous 
to exporting definitions from a DLL."

Cool. Problem is access/visibility rules for symbols that are 
_not_ marked with "export" is not defined and looking and 
generated binaries is not enforced in any way by dmd at least. 
Which makes export kind of joke.

Well, pardon me, I probably have exceeded my allowed daily rant 
limit :)