On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
> Well, that is one of rather inconvenient issues with D handling of emitting symbols (this one kind of inherited from C++). extern(X) defines both mangling and calling convention. You can't have those separately now.

Yeah.

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.

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 :)

On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
> Well, pardon me, I probably have exceeded my allowed daily rant limit :)

Don't worry, and I agree with you. But I think it's probably too late to actually change what a linkage specifier does for nested symbols. We might end up getting duplicate symbol definition errors (hello Optlink..) in completely unrelated libraries if mangling changes for these symbols.

On Wednesday, 8 May 2013 at 19:14:14 UTC, Andrej Mitrovic wrote:
> On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
>> Well, pardon me, I probably have exceeded my allowed daily rant
>> limit :)
>
> Don't worry, and I agree with you. But I think it's probably too late
> to actually change what a linkage specifier does for nested symbols.
> We might end up getting duplicate symbol definition errors (hello
> Optlink..) in completely unrelated libraries if mangling changes for
> these symbols.

I've undestood, that function mangling is a difficult issue.
But what about extern variables? 	
Obviously, when user write ("extern(C) extern int var;"), he want to get extern variable with C mangling. Another way: get second parameter (symbol name) to extern attribute.
E.g.
extern(C, "@FOO@")void FOO(int); //have C linkage and @FOO@ mangling
extern(C)void FOO2(int); //have C linkage and C (or D, if FOO2 is local symbol) mangling
extern("__FOO__") void FOO(int); //have D or System linkage and "__FOO__" mangling


However, I would like to mangling argument of extern attribute will be evaluatable form any string expression.
enum MANGLING = "@@@M@@@";
extern(D, MANGLING) int boo();