Re: [boost] smart ptr changes

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-20 19:37:49

Peter Dimov wrote:
> 
> From: "John Max Skaller" <skaller_at_[hidden]>
> > > > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226
> > > > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1296.htm
> >
> > Be interesting to see the proposed syntax.
> 
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1295.htm
> 
> > Here's mine:
> >
> > // primary template
> > template<class T, class U> void f(T,U);
> >
> > // specialisation
> > template<class X> template<class T=X, class U=X> void f(T,U);
> >
> > There isn't any alternative to fully repeating the whole
> > signature. Unless I'm mistaken, this ALSO applies to
> > full specialisations, which means the current syntax is
> > plainly wrong.
> 
> You are right; 

        I analysed this years ago. I wouldn't support
the proposal in N1295 for that reason.

> I didn't try to fix the current syntax, though, merely to extend it.

        Creating even more problems for template meta-programming?
Bad idea. It isn't a question of 'fixing' the current syntax,
since there is none for partial specialisations.

        If you just propose a _correct_ syntax for
partial specialisations, you are left with an existing
problem with full specialisations. No loss here:
the problem already exists, and you haven't created a new one,
but you have AVOIDED creating a total nightmare.

        You've also suggested a _correct_ resolution
to the full specialisation problem: deem them
as overloads, and use the proper syntax

        template<> 
        template<class T=int>
        void f(T)

for full specialisations. The question is: what will this
break? And the answer is: less than you think, because
originally the ARM:

        void f(int);

was effectively the same as an overload. Namespaces
may create a problem. I don't know. The point is that
there is a migration path to a correct solution.
Without function template specialisations, a lot of problems
seem to arise (swap is only one of them).

Doing it right sometimes costs in the short term,
but it pays off in the long term. C++ is here to stay
for a while. The sooner this is fixed the better.

I note that having BOTH function template overloading
AND partial specialisation is complex. But the ideas
are orthogonal, and at present we use one technique
for classes, and the other for function templates.
This just isn't consistent.

If this could be fixed, we could also, finally,
allow _function_ templates to be passed to templates,
because finally we'd have a syntax for it.
Finally, a template-id can be an actual _identifier_:
something that uniquely names a template instance. For a
function template:

        f<int,long>

isn't enough. It doesn't say which f. You must write:

        template<class T=int, class U=long> f(T,U)

for a function template instance to identify it.
And THAT should be fixed (in the grammar) as well.

The most likely hurdle is NOT syntax or compatibility
with legacy source, but breaking poorly constructed
ABIs which can't be extended to supported partial
specialisation of templates. I can't see that this
problem can arise easily, since templates aren't
run time objects, but I could be wrong.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net