🚀 go-pugleaf

IMHO the standard should say something like:
1. 'extern "XXX"' linkage _allows_ the compiler to use create code differently
   to 'extern "YYY"' linkage.
2. For names with external linkage that is not 'extern "C++"' there _may_ be
   restrictions compared to 'extern "C++"'.
3. Any C++ compiler shall support at least 'extern "C++"' and 'extern "C"'.
4. If not noted otherwise this standard describes only the behavior of
   'extern "C++"' linkage.
5. If a name from the Standard C Library is not 'extern 'C++"' then it
   _shall_ be 'extern "C++"' (see 17.3.2.2,2). 'extern "C"' linkage _should_
   allow _further_ compatibility to C implementations.

IMO this gives us what we want and what we can get:
ad 1. A compiler which allows 'extern "Fortran"' is still a legal C++ compiler.
ad 2. It is _legal_ (but not necessary and not in the scope of the standard)
      to have a restriction like
      - functions with extern "C" linkage can not be overloaded
      - functiontypes with extern "Pascal" linkage are not compatible to
        functiontypes with extern "C" or "C++" linkage.
ad 5. As we've seen in the discussion before, it is not sensible to require
      compatibility to a specific C implementation. It not even makes sense
      to make it implementation defined to which it is compatible, as there
      might be no C implemenation at all or it could just name C implementations
      that are not available (yet / any more).


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Schünemann
Fakultät für Informatik, Technische Universität München, Germany.
email: schuenem@informatik.tu-muenchen.de
WWW:   http://www.informatik.tu-muenchen.de/cgi-bin/nph-gateway/hphalle2/~schuenem/index.html
...there is only one way to "skin a C+@"...:)  -- Jim Fleming