🚀 go-pugleaf

	Consider the following piece of code.

typedef enum
  {
    e1,
    e2
  } E;

int main(int argc, char **argv)
  {
    E e;
    e = e2;
    return 0;
  }

Should it typecheck? My naive reading of the standard suggests that the 
expression e = e1 is not type correct, but this conclusion seems too brain
damaged to be believable.   What am I missing?   Here is my reasoning.

e (and e1, for that matter) are of enumerated type, so overloading
resolution comes into play.   There are no user defined overloadings
of operator =, so we need only consider the built in overloadings.
For each arithmetic type L, every promoted arithmetic type R and every 
VQ that is either volatile or empty, there is a built in overloading
of operator =
	
	VQ L & operator =(VQ L &, R).

And for every type T and every VQ that is either volatile or empty,
there is a built in overloading

	T* VQ & operator =(T* VQ &, T*).

None of these seems to be a viable candidate.  There are no implicit 
conversions from enumerated types to pointer types, so there doesn't seem to 
be any way for any of the T* VQ & operator = (T*VQ&,T*) functions to be viable.
For any arithmetic type L, an _rvalue_ of type E can be converted implicitly
to L, but the result is an _rvalue_ of L, which cannot then be bound to the 
a reference to non-const, as required by the first parameter of the functions
VQ L & operator =(VQ L &, R).   Moreover, there doesn't seem to be any 
implicit conversion that converts an lvalue of enumerated type to an 
lvalue of arithmetic type [note that enumerated types are _not_ arithmetic
types].   Thus, the more likely looking VQ L & operator=(VQ L &, R) 
overloadings don't appear to be viable either.

Enums seem to be the only possible problem types.   Arithmetic types, and
pointer types seem to be adequately handled by the built in overloadings.
Class, structs and unions either have user defined assignment operators
or implicitly defined assignment operators.   Assignment to arrays and 
functions isn't supposed to work.   The only remaining types are enum types.

Bill.
	

--
William E. Aitken 			    | Formal verification is the 
email: aitken@halcyon.com                   |  future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA  | Always has been, always will be.
===============================================================================

---
[ 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. ]