Revision 12 of the C++ Standard core language issues list is now
available in the usual places:

      http://www.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html
      http://www.comeaucomputing.com/iso/cwg_active.html

I just noticed that I forgot to include an entry in the history
list for revision 12.  However, this revision reflects the
work of the core language group at the Tokyo meeting in April,
as well as a number of newly-reported issues since the previous
published version.  We did a lot of drafting work at that
meeting, so there are a large number of issues with detailed
proposed wording for resolutions.

Because we are getting close to issuing a Technical Corrigendum
for the Standard, I'd like to encourage people to review this
list to help us find things we've overlooked or which might not
be expressed clearly.  In particular, please look at the issues
with "ready" and "review" status.  The proposed resolutions for
these issues, along with those that have already been accepted
by the Committee as defect reports, will form the bulk of the
TC for the first sixteen clauses of the Standard, and we'd
_very_ much like to avoid having to "fix our fixes" later;
your help in early detection of problems will be appreciated.

If you find something questionable, you can either notify me
directly at wmm@fastdial.net or post a message to this
newsgroup.  If you choose to post, please CC me on the
message; I expect to read the group regularly, but email is
more reliable.

Thanks in advance for your help.

-- William M. Miller



     -----  Posted via NewsOne.Net: Free Usenet News via the Web  -----
     -----  http://newsone.net/ --  Discussions on every subject. -----
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Am 02.06.00, 07:13:22, schrieb Hyman Rosen <hymie@prolifics.com> zum Them=
a=20
Re: New core language issues list now available:


> wmm@fastdial.net writes:
> > If you find something questionable

> 176. Name injection and templates

> Does the proposed resolution handle the case of using the template name
> as a template template parameter?

> I think the following code should be legal.

> template <typename T, template <typename> class C> struct A { C<T> c; }=
;
> template <typename T> struct B { A<T,B> *a; }

> On the other hand, the requirement that use of an unadorned B inside th=
e
> definition of B is always considered to be equivalent to B<T> could mak=
e
> this illegal.

It seems that you must replace the second line by

   template <typename T> struct B { A<T,::B> *a; }

This extends, of course, to the use of B as a template name in the=20
definition of a member function of B.

I agree that this is counterintuitive. It also violates the spirit of the=
=20
proposal which says that:
 "Clearly the injected name must be usable as both a class and a class=20
template."

OTOH it seems there is a possible ambiguity if the use as a template=20
template parameter is allowed:

   template <typename C> void f();
   template <template <typename> class T> void f();

   template <typename> struct B { void g(); };

   template <typename X>=20
   void B<X>::g()
   {
      f<B>(); // f< ::B>() or f< B<X> > or ambiguous ?
   }

BTW: Are there any other uses of a (class) template name besides (a) as=20
part of a template-id and (b) as an argument for a template template=20
parameter ?


Regards, J=F6rg

--
J=F6rg Barfurth                   j barfurth AT vossnet DOT de
-------------- using std::disclaimer; ----------------------
Software Engineer               Tel: +49 40 23646 500
Star Office GmbH                Fax: +49 40 23646 550
Sachsenfeld 4                   mailto:joerg.barfurth@germany.sun.com
D-20097 Hamburg                 http://www.sun.com/staroffice


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

joerg.barfurth@attglobal.net (J=F6rg Barfurth) wrote in
<20000602.11420535@jb-11116.stardiv.de>:

>Am 02.06.00, 07:13:22, schrieb Hyman Rosen <hymie@prolifics.com> zum The=
ma
>Re: New core language issues list now available:
>
>> I think the following code should be legal.
>
>> template <typename T, template <typename> class C> struct A { C<T> c; =
};
>> template <typename T> struct B { A<T,B> *a; }
>
>It seems that you must replace the second line by
>
>   template <typename T> struct B { A<T,::B> *a; }

That is correct.  The proposed resolution is not a change from
the status quo in this respect.

>This extends, of course, to the use of B as a template name in the
>definition of a member function of B.
>
>I agree that this is counterintuitive. It also violates the spirit of th=
e
>proposal which says that:
> "Clearly the injected name must be usable as both a class and a class
>template."
>
>OTOH it seems there is a possible ambiguity if the use as a template
>template parameter is allowed:
>
>   template <typename C> void f();
>   template <template <typename> class T> void f();
>
>   template <typename> struct B { void g(); };
>
>   template <typename X>
>   void B<X>::g()
>   {
>      f<B>(); // f< ::B>() or f< B<X> > or ambiguous ?
>   }

The general principle is that you have to determine the kind (type,
non-type, or template) of a template argument based solely on the
argument itself, because you might not have a parameter to tell you
what is expected.  Overloaded functions, as you point out, are one
such case; another is when the template name is dependent (e.g.,

     X::template Z<B>

where you have no declaration of Z to give you the template
parameter that matches B).

Rather than complexify the rules to allow use of the unqualified
template name as a template template argument whenever there is
a matching template template parameter, we just stayed with the
simpler approach of requiring a qualified-id for all such cases.

>BTW: Are there any other uses of a (class) template name besides (a) as
>part of a template-id and (b) as an argument for a template template
>parameter ?

I don't believe so.

--
William M. Miller, wmm@fastdial.net


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]