Re: [v3] mutex linkage cleanup

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Paolo Carlini <pcarlini@suse.de> writes:

| Benjamin Kosnik wrote:
| 
| >Noticed as part of libstdc++/22309.
| >
| I see your (and Jakub's) point.
| 
| However, since the days Zack used static in basic_file_stdio.cc, I have
| an annoying itch (*), related to this sentence in C++SE, §9.2:
| 
|     "In C and older C++ programs, the keyword static is (confusingly)
| used to mean "use internal linkage". Don't use static except inside
| functions and classes."
| 
| Maybe Gaby can help in an exegesis of Bjarne's point?

Since the very beginning of C, "static" was designed to mean "a single
copy of this stuff in the whole program" -- as, e.g., used for local
variables with static storage.  Then a distraction happened; users
wanted to have functions local to translation units.  So some
analogies were constructed to extend "static" to cover "linkage". 

When the issue poped up for C with Classes and C++, "static" was
generalized using the *original* intent ("a single copy in the
translation unit") for class-wide data members (and functions).
Remember, a class can be viewed as a module.

The true is neither DRM nor BS appreciate much the use of "static" to
specify "linkage".  There is an interesting account of DRM's expressed
feeling about "linkage" during a discussion after DMR's presentation
of C at the second HOPL (History Of Programming Language) -- a (highely 
selective) conference that takes place every 15 years and not
every programming language qualifies. 


The introduction of unnamed namespace was partly motivated by the
desire to restore original intent, and as a consequence dealing with
weird restrictions on template arguments and bodies.

If the back-end (and not the front-end!) can understand that entities
in unnamed translation units are local to their translation unit, then
that would be an effective support of the language functionality and
would make it more widely used.

-- Gaby