Is it correct?
When I wrote next code:
template Extern(string s)
{
    mixin("static extern(C) extern int "~s~";"~
    "alias Extern = "~s~";");
}
void main()
{
    writeln(&Extern!("xxx"));
}
I get error message "undefined reference to `_D1a24__T6ExternVAyaa3_787878Z3xxxi'", when I expect to get "undefined reference to `xxx'"?
Is it error?

May be I need to fix that issue? What about functions?

struct Foo
{
  extern(C) void bar()
  {

  }
}

Is it good to set bar mangling to "bar"?

On 5/7/13, Igor Stepanov <wazar.leollone@yahoo.com> wrote:
> struct Foo
> {
>    extern(C) void bar()
>    {
>
>    }
> }
>
> Is it good to set bar mangling to "bar"?

No. For one example, internal extern(C) functions can be used for callbacks. You wouldn't want linking to fail if you have this code:

struct A
{
    extern(C) void callback() { }
}

struct B
{
    extern(C) void callback() { }
}

On Wednesday, 8 May 2013 at 09:09:34 UTC, Andrej Mitrovic wrote:
> ...

Suck code is invalid in C++ and for a good reason. I'd really expect D to refuse to compile extern(C) functions it can't possibly mangle correctly.

On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
> On Wednesday, 8 May 2013 at 09:09:34 UTC, Andrej Mitrovic wrote:
>> ...
>
> Suck code is invalid in C++ and for a good reason. I'd really expect D to refuse to compile extern(C) functions it can't possibly mangle correctly.
>

Sorry, I forgot I was actually thinking about *static* extern(C) functions. I'm not sure about methods.

On Wednesday, 8 May 2013 at 09:22:52 UTC, Andrej Mitrovic wrote:
> On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
>> On Wednesday, 8 May 2013 at 09:09:34 UTC, Andrej Mitrovic wrote:
>>> ...
>>
>> Suck code is invalid in C++ and for a good reason. I'd really
>> expect D to refuse to compile extern(C) functions it can't
>> possibly mangle correctly.
>>
>
> Sorry, I forgot I was actually thinking about *static* extern(C)
> functions. I'm not sure about methods.

static methods are illegal in C++ with extern(C) too. As well as any namespaced function. Or any function that has overloads.

On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
> static methods are illegal in C++ with extern(C) too.

I don't see why. They're useful in D anyway.

On Wednesday, 8 May 2013 at 09:46:00 UTC, Andrej Mitrovic wrote:
> On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
>> static methods are illegal in C++ with extern(C) too.
>
> I don't see why. They're useful in D anyway.

Because they have namespace (class namespace) and can't be mangled according to C rules. Exactly your example. You can't have two "foo"'s there but any other naming scheme IS NOT C mangling but some weird abomination that pretends to be it. Thus it is a compile-time error.

On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
> Because they have namespace (class namespace) and can't be mangled according to C rules. Exactly your example. You can't have two "foo"'s there but any other naming scheme IS NOT C mangling but some weird abomination that pretends to be it. Thus it is a compile-time error.

Right, you may not be able to statically link with it but it's still a calling convention, so it's useful (for callbacks).

On Wednesday, 8 May 2013 at 09:56:14 UTC, Andrej Mitrovic wrote:
> On 5/8/13, Dicebot <m.strashun@gmail.com> wrote:
>> Because they have namespace (class namespace) and can't be
>> mangled according to C rules. Exactly your example. You can't
>> have two "foo"'s there but any other naming scheme IS NOT C
>> mangling but some weird abomination that pretends to be it. Thus
>> it is a compile-time error.
>
> Right, you may not be able to statically link with it but it's still a
> calling convention, so it's useful (for callbacks).

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. Saying in one case it is both mangling and ABI and in other one it is only ABY smells like broken specification/implementation.

Actually I remember discussing this with Volt language team recently. Currently relation between D type system and emitted symbols is not that well-defined in spec and this is one of many cases where it causes problems. I don't think it can be fixed without some sort of overhaul.