Why does C++ disallow unnamed structs and unions?

Question

Some C++ compilers permit unnamed unions and structs as an extension to standard C++. It's a bit of syntactic sugar that's occasionally very helpful.

What's the rationale that prevents this from being part of the standard? Is there a technical roadblock? A philosophical one? Or just not enough of a need to justify it?

EDIT: Sorry, I must have the terminology wrong. Here's a sample of what I'm talking about:

struct vector3 {
  union {
    struct {
      float x;
      float y;
      float z;
    };
    float v[3];
  };
};

My compiler will accept this, but it warns that "nameless struct/union" is a non-standard extension to C++.

Answer 1

Not sure what you mean. Section 9.5 of the C++ spec, clause 2:

A union of the form

union { member-specification } ;

is called an anonymous union; it defines an unnamed object of unnamed type.

You can do things like this too:

void foo()
{
  typedef
  struct { // unnamed, is that what you mean by anonymous?
    int a;
    char b;
  } MyStructType; // this is more of a "C" style, but valid C++ nonetheless

  struct { // an anonymous struct, not even typedef'd
    double x;
    double y;
  } point = { 1.0, 3.4 };
}

Not always very useful... although sometimes useful in nasty macro definitions.

Answer 2

Unions can be anonymous; see the Standard, 9.5 paragraph 2.

What purpose do you see an anonymous struct or class as fulfilling? Before speculating why something isn't in the Standard, I'd like to have some idea why it should be, and I don't see a use for an anonymous struct.

Answer 3

Your code

struct vector3 {
  union {
    ...
  };
};

is like

struct Foo {
   int;
};

which is surely invalid.

The reason is probably to simplify parsing (in C), because in that case you only need to check that the struct/union body has only "declarator statements" like

Type field;

That said, gcc and "other compilers" supports unnamed fields as an extension.

Answer 4

Based on the edit, the comments, and this MSDN article: Anonymous Structures, I'll hazard a guess - it fits poorly with the concept of encapsulation. I wouldn't expect a member of a class to mess with my class namespace beyond merely adding one member. Furthermore, changes to the anonymous structure can affect my class without permission.