In article <rfgCD2zxz.5p9@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>Andrew,
>
>The original point at issue was how to provide a notation (in the language)
>by which programmers could specify which members of template formal types
>are themsleves types.
>
>You suggested a notation like:
>
> template <class T> class TMPL
> {
>  class T::M;
>  ...
> };
>
>You then claimed that this notation had "the advantage of requiring no
>really new syntax".  But you failed to specify which other alternatives
>this "advantage" was relative to.
>
...
>
>I would agree that the meaning of a declaration like class T::M; should
>be mostly obvious to experienced C++ programmers.
>
>However I should also mention that (likewise) the notation I have informally
>suggested here previously *also* has the advantage of requiring no "really"
>new syntax, and it *also* should be immediately and intutively obvious for
>experienced C++ programmers.
>
>Just in case you (or anyone else) may have forgotten what it looked like,
>here again is a short example of the notation I had suggested:
>
> template <class T { class M; }> class TMPL
> {
>  ...
> };
>
>I actually believe that this is MORE intutively obvious than the notation
>you have suggested (however I *do* admit to being a bit biased on this point).
>

It's a nice syntax, but unfortunately it looks too much like constrained
templates (to me at least). There are some of us that think that constrained
templates are a good idea, and might want to save the notation for C++++:-)

Andrew's proposal does have other side benefits (though I'm sure he didn't
imply them in his proposal). In current C++ when we say

    class X;

means that X is a class or struct. Under Andrew's proposal, X is *any* type.
Thus we can forward declare any type, including enums. We can thus write:

     //======= Eg.h
     class Enum;

     struct X {
         Enum& e;
         X();
     };


     //======= Eg.cpp

     enum Enum {Zero,One,Two};

     X::X() : e(Zero) {}


This feature is not often important, but it does come in handy from time to
time. I'm sure this syntax has a little more mileage in it.

>--
>
>-- Ronald F. Guilmette ------------------------------------------------------
>------ domain address: rfg@netcom.com ---------------------------------------
>------ uucp address: ...!uunet!netcom.com!rfg -------------------------------


Take care
    Robert
--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/

In article <1993Sep11.030758.20347@cdf.toronto.edu> g2devi@cdf.toronto.edu (Deviasse Robert N.) writes:
>... Under Andrew's proposal, X is *any* type.
>Thus we can forward declare any type, including enums. We can thus write:
>
>     //======= Eg.h
>     class Enum;
>
>     struct X {
>         Enum& e;
>         X();
>     };
>
>
>     //======= Eg.cpp
>
>     enum Enum {Zero,One,Two};
>
>     X::X() : e(Zero) {}

Wow!  Talk about people seeing just what they want to see (in a proposal)!

I don't think that Andrew ever suggested that it should be possible to
produce the kinds of semantics you envision via the notation `class T::M;'.
(If that's what he *meant* to say, then let him say so.  I certainly didn't
see that mentioned in anything he's said on this topic.)

Also, I don't recall Andrew ever even mentioning the possibility that the
``class T::M;' notation would be usable OUTSIDE of template definitions.
(Again, if that's what *he* envisioned, let him say so.)

In general, I think you will find that for essentially ANY plausible
small addition to the existing syntax rules, any person with an ounce
of creativity will be able to postulate a myriad of POTENTIAL things
that the given new syntactic notation could (in theory) be used to
signify, but that seems to me to be a undisiplined approach to the
evaluation of alternative solutions for a specific problem.  (You may
recall that the specific problem we were discussing was how to provide
a way to specify which members of template formal types are themselves
types.)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

I argue against the syntax proposed by Andrew Koenig:

 class T;  // T is some type

because I think it is unintuitive if T really is a non-class type.
The example here, stolen from a previous posting, shows why:

>>     class Enum;
>>
>>     struct X {
>>         Enum& e;
>>         X();
>>     };
>>
>>     enum Enum {Zero,One,Two};

The problem is not only enumerated types, but also built-in types and
aggregate types defined with typedefs, e.g.,

 typedef double TransformationMatrix[4][4]; // 3D

I would instead favour an alternative syntax which cropped up during
discussions at a recent standards meeting:

 typedef T;  // T is some type

The problem here is that it probably already has a meaning (!), namely
that "T" is an "int" -- this is known as the "implicit int rule."
Implict int causes no end of trouble in C++, for example, in
determining if an identifier is a varible or a type:

 extern void f(const T);

Does f take an argument of type "const T", or does f take an argument
of type "const int" that we have called "T"?  (Nb. The ARM does indeed
say what this means.)

This designed-in problem is a sacrifice on the holy altar of C
compatibility, and it is probably hopeless to "outlaw" implicit int in
the forthcoming C++ standard.  However, I think it would be great if
we would could make strong statement that implict int is bad practice
and pave the way for outlwaing it in the next revision of the C++
standard.

If you have any oppinion on outlawing implict int *now*, please send
me mail.

   -- Dag Bruck
      dag@control.lth.se