Re: Static linkage and anonymous namespace

[Jason Merrill <jason at cygnus dot com>]

>>>>> Mark Mitchell <mark@markmitchell.com> writes:

>>>>> "Martin" == Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:
 >>> So, we can make it `static' in the C sense.  So, it's fair to
 >>> warn on:
 >>> 
 >>> namespace { struct S {}; } void f(vector<S> vs);
 >>> 
 >>> but it's not fair to make that an *error*; it's actually legal,
 >>> I think.

 Martin> Why would I even warn on that? If I later get an
 Martin> implementation for f, fine, if I don't - well, I can't
 Martin> supply one in another translation unit, so it remains
 Martin> unresolved.

 > In the latter case in it's certainly reasonable to warn; if there's no
 > implementation, then, as you point out, there's no way to *ever*
 > define the functions, so a warning is in order.  This is akin to a
 > "static-function-declared-but-not-defined" warning.

Agreed.

 > Even in the first case it's reasonable to warn; there's no point in
 > giving external linkage to such a function since it can't really be
 > called from somewhere else.

No; 'static' is deprecated, now that we have the unnamed namespace.

 > I'm not particularly interested in scrapping over whether or not the
 > warnings I proposed are useful; I'm more interested in not going to a
 > lot of trouble to give functions that involve types in anonymous
 > namespaces internal linkage.

 > In fact, I'm not even sure we should give functions in an anonymous
 > namespace internal linkage.  Maybe we can dream up cases where people
 > will use assembly language to call them from other files?  It seems
 > simplest to map C++'s internal/external linkage directly onto
 > traditional linker semantics.

Yep.

Jason