In article <rfgCD7B58.8ny@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>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.)


You editted to efficiently, eariler in the article I said:
 "Andrew's proposal does have other side benefits (though I'm sure he didn't
                                                   ^^^^^^^^^^^^^^^^^^^^^^^^^
  imply them in his proposal)."
  ^^^^^^^^^^^^^^^^^^^^^^^^^^

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

I admit I might have been a little ambiguous. I apologize if this is so. I
did not mean to imply that Andrew endorsed what I proposed.

This thread started some time ago so I've forgotten some of the details of all
the proposal, but I do remember near the beginning of the thread that the
suggested notation would have the unfortunate side effect that "class int"
would be made legal. I *don't* remember if Andrew said this, but I didn't
see a word to the contrary, and so I assumed that it implied that this
notation could be used outside of templates.

I simply suggested that, since it should be just as easy for a compiler
to understand a forward declaration of a type inside a template as outside,
allowing one forward declaration but not the other to exist would appear
to be an arbitrary decision with no advantage. Admittedly, the semantic
advantage is small, since the above could be simulated via:

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

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


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

     struct Enum {
         enum Type {Zero,One,Two};
         Type value;
         Enum(Type v) : value(v) {}
     };

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

Ugly, but it works. I just suggested this since I didn't think another
special case should be added to C++, even if it is trivial, unless it is
necessary.

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

Yes, but what I suggested does seem to follow *if* the notation could be
used outside of templates. Could you suggest a reason why this
nonorthogonality would benefit the language?

>
>--
>
>-- 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"|
+----------------------------------+------------------------------------------/