Re: Getting 3.3 out the door

[Joe Buck <jbuck at synopsys dot com>]

On Thu, 2003-04-10 at 15:02, Wolfgang Bangerth wrote:
> > 
> > Can I lobby a little for c++/9393? I only rediscovered this these days, so 
> > I doubt anyone has looked at it with an angle on 3.3 (because it didn't 
> > have priority "high" until very recently). It's
> > - a problem that one cannot work around
> > - generates code that cannot be linked
> > - violates the C++ standard
> > - a regression against 2.95
> > - breaks my application and prevents Brad from running it on his system :-)

On Thu, Apr 10, 2003 at 03:16:18PM -0700, Mark Mitchell wrote:
> We've already fought about this one. :-)  See my "Release-Note" there.
> 
> This one can't be fixed in the 3.3 time frame, I don't think.

There is a relatively simple, though controversial, "fix": treat
anonymous namespace names as static.  There are some problems with
that solution, for example, the question of what happens if there's
a template defined on a type declared in the anonymous namespace, as
well as a few other oddities like that, but the committee intended
anonymous namespaces to replace "static", so in the majority of cases
it should be possible to handle it in the same way.

Even in cases where we don't have a link failure as in 9393, we are
degrading link performance for users that listen to the committee and
replace file-static by anonymous namespace usage.

Possibly some compromise based on filtering could be acceptable: if
there's no reason why an anonymous namespace symbol must be exported,
don't export it, but do export it in cases where this is needed.  This
would not completely eliminate the issue, but it would reduce the damage.
That is, only generate anonymous namespace symbols as global in cases
where they are used in a way that requires global-ness.