🚀 go-pugleaf

Hi people!
I want to share some thoughts on the template section of the (April) draft
standard (BTW, is ASCII version of September one is available somewhere?
Easily editable/reformattable version (e.g. WinWord or RTF) would be even
better).
Generally, I like it  very much. In fact while reading it I had that
'Here-is-what-I-longed-for' feeling which I last had (programming-wise)
when reading Stroustroup's book 5 years ago. Some things I do not
understand, however, and would like the committee members to provide
'rationale on demand' and explain what is the point of some finer points.

1) Clause [temp.res] verse 1 requires that all types dependent on the
template parameter must be qualified by 'typename' keyword - supposedly to
allow checking the template syntax. But it does not help anything as _each_
instance will have to be checked anyway:
  e.g.
     struct X {
      static int A;
      class B {  };
     }
     template <class T> class Y {
      typename T::A *ap;     // error in Y<X> - T::A is not a type
      T::B *bp;              // error - no 'typename'
     }
2) Clause [temp.dep] verse 5 states that base class scope names hide the
template parameter:
    struct A { struct B{}; };
    template <class B, class C> struct X : A {
      B b;   //A's B
    };
However, as base class is the enclosing scope, I would intuitively expect
anything related to the derived class (its template parameter, for
instance) to hide its names. Moreover, we can use A::B to access A's B -
while template parameter is now inaccessible. Also, base class definition
may be inaccessible. Of course, you can change the temp. param. name - but
anyway it is not nice.
3) Clause [temp.arg.explicit] verses 2-3 requires that for explicit arg in
member template to be present it must be qualified by 'template' keyword,
e.g.
     X *p; p->template alloc<200>();
But to use operator -> we need X class definition anyway - so we know that
alloc() is a template. Thus this keyword is redundant and likely to be
forgotten (if I am not mistaken, it is in fact missing from some examples
in lib.locale section).
4) Clause [temp.deduct] verse 4. Why the conversions other than Derived* ->
Base* are not allowed in template deduction (at least default conversions
like char->int; user conversions would be even better)?

          Best regards                      Genie

PS. Am I the only one who does not like the current drift in the C++ syntax
from symbolic (C-like)
   int a[10];
to verbose (Pascal-like)
   var
     a: array[0..9] of integer;
way of expressing things? Why don't use, for instance, cast_d instead od
dynamic_cast (ugh). Yeah, I know we are not using 10-cps terminals Richie
(sp?) did, but anyway... (and it consumes compiler memory space :-)


--
--------------------------------------------------------------------
Eugene V. Radchenko           Research associate, Computer Chemistry
E-mail: eugene@qsar.chem.msu.su                Fax: +7-(095)939-0290 
Ordinary mail:  Chair of Organic Chemistry, Department of Chemistry,
                      Moscow State University, 119899 Moscow, Russia
*****************  Disappearances are deceptive  *******************
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]