<div dir="ltr">On Wed, Sep 25, 2013 at 6:23 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> I'll also explain the reasoning behind our implementation, which is<br>

> borne of practical needs as much as correctness:<br>
><br>
> Language linkage specifications can only appear at namespace scope<br>
> ([dcl.link]p4).<br>
><br>
> So this is invalid:<br>
> class ... {<br>
>   friend extern "C" int bar(Foo *y);<br>
> };<br>
><br>
> Therefore pre-declaring the desired language linkage and retaining it in<br>
> the friend declaration is the _only_ way to implement a friend function<br>
> with different language linkage to its declaration context.<br>
<br>
</div>I think I agree. Even if this is not standard compliant, it seems a<br>
useful gcc/msvc extension and less crazy than other extensions we<br>
support.<br>
<br>
Richard, do you see a case where supporting this extension (assuming<br>
it is one) would break standard conformant code?</blockquote><div><br></div><div>I'll give it some more thought, but I don't think so. I'm happy to support this as an extension if not -- for me the most convincing case is something like:</div>
<div><br></div><div>extern "C" int f();</div><div>extern "C++" int g();</div><div>struct S {</div><div>  friend int f();</div><div>  friend int g();</div><div>};</div><div><br></div><div>I think it's impossible for S to befriend both f() and g() with the current behavior. (Though one might argue that you could factor out the implementation of f() into a function that is not extern "C", so this isn't necessarily a critical issue, but it is inconvenient.) </div>
</div></div></div>