Proposal for mangling template partial specializations.

[Mark Mitchell]

I'm not persuaded that we should mangle specializations and
instantiations differently.  If I understand Colleen's proposal, these
two functions:

  template <class T> void f(T);
  template <> void f<int>(int) {}

and

  template <class T> void f(T) {}
  template void f<int>(int);

(the first a specialization, the second instantiation, would be
mangled separately.)  If I misunderstood, then I apologize, and only
some of it what follows is relevant.

Here are my objections:

  o Real code depends on being able to intermix the two.  In fact,
    this is a historical way of putting instantiations in libraries:
    you declare a specialization, but then provide an explicit
    instantiation in the library.  That prevents clients of the
    library from doing implicit instantiations.

  o I don't think the standard doesn't require a diagnostic.

  o There are other wways of getting a diagnostic, if you want one,
    other than mangling.  In fact, mangling is probably not likely
    to yield useful diagnostics: the message will just be
    "xyz undefined", not "you mixed an instantiation and a
    specialization".  Other mechanisms could be used for that.
    (Analagous here is the ODR: you could mangle into every inline
    function its token sequence, and then check the ODR at link-time.
    But, you'd be better off to store this on the side.)

  o Real implementations are underway.  We have to start taking making
    changes to the draft ABI more seriously.  We're already
    implementing the ABI in two different compilers, and I expect
    others are doing the same.  It's important that we have compilers
    ready as quickly as possible; the chip is almost live, and we
    don't want there to be a substantial installed base of
    non-compliant compilers; that will substantially reduce the
    value of the work this committe has done.  If it ain't broke,
    we really shouldn't be fixing it now.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com