Re: C++ nested classes, namespaces, structs, and compound statements

[Jim Blandy <jimb@redhat.com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> Sure.  But I think this is a chance (if we want one) to move in a
> different direction.  We'd have to work out the details, but I envision
> something like this (names made up as I go along):
> 
> struct environment_entry {
>   const char *name;
>   enum name_type kind;
>   void *data;
> }
> 
> enum name_type {
>   type_kind,
>   field_kind,
>   symbol_kind,
>   namespace_kind,
> };

In other words, replace the sloppy union with a properly discriminated
union?  I'm for it.

But granted that it's important to clearly distinguish between the
expanding set of uses we're putting `struct symbol' to, and that
extending enum address_class isn't the best idea, how is it better to
make this change concurrently with the enclosing environment changes?
We could do this change right now.  Isn't it basically independent?


Getting too technical for this point in the discussion: I like doing
subclassing of structs in C like this:

struct environment_entry {
  const char *name;
  enum name_type kind;
};

struct field_entry {
  struct environment_entry env;
  enum field_visibility visibility;
  struct type *type;
  ...
};

Since C guarantees that a pointer to a struct can be safely converted
to a pointer to its first member and back, this is okay.  And while
going from superclass to subclass still isn't typesafe, going from
subclass to superclass is.  (The down-casting should be hidden in a
function which also checks the tag.)

But this is just bikeshedding.  I like your basic idea, however one
implements it.