Proposal for mangling template partial specializations.

[Coleen Phillimore]

Mark Mitchell wrote:
> 
> 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.

Yes, you understood correctly.

> 
> 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.

We have a #pragma do_not_instantiate which we use for that purpose.
Supporting pre-instantiation libraries is very important to us as well.
Unfortunately, other than a pragma, there doesn't seem to be a cleaner
way to do this.

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

No, it doesn't.  But does the standard prohibit linking a specialization when
an instantiation is required?  Is this something that Perennial can write a
test for?

> 
>   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.

>From my perspective, it is broke.  It prevents conforming implementations
from being ABI complaint.  Unlike this ABI, the C++ standard has been
voted in and has "shipped".  If different implementations choose to implement
the C++ language differently (that implementations can see), there's a
bigger effort wasted.

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

-- 
-----------------------------------------------------------------------
Coleen Phillimore                  | mailto:coleen at zko.dec.com
Compaq Computer Corp.   Nashua, NH | COMPAQ C++ Compiler Development
-----------------------------------------------------------------------