Re: [PATCH] Use variants to support objects as semantic values.

[Paolo Bonzini]

> I used "%define variants" for lack of a more intelligent name.  Joel,
> you might have an opinion about this.  Maybe api.type.variants?

Maybe stype.variants?  It does not need to affect the API, because you
can use a wrapper around the union if variants are not used, so that the
as<> API works in both cases:

#include <cassert>

union u {
  char a;
  int b;
};

template<class U>
class union_variant {
  U data;
 public:
  template <typename T> T& as() {
    return reinterpret_cast<T&>(data);
  }
  template <typename T> const T& as() const {
    return reinterpret_cast<const T&>(data);
  }
  operator U&() { return data; }
  operator const U&() const { return data; }
};

int main()
{
  union_variant<union u> v;
  union u& test = v;
  test.a = 10;
  assert (v.as<char>() == 10);
}

The Bison parser would use a stack of union_variant<stype>'s and export
that as parser::semantic_type, but the parser::YYSTYPE would be a union.
for backwards-compatibility.  In other words:

- parser::semantic_type is always accessed with as<>

- parser::YYSTYPE is not defined at all for variants, and is a union
otherwise.

In the medium term variants could be made the default, but in the
meanwhile there would be a way to write parsers that work both for
unions and for variants.  What do you think?

> I just say that the java skeleton now uses %define stype, which is
> correlated.  I regret that the names were not discussed first, now we
> face a lack of structure, although Joel had been careful up to now to
> propose something consistent.

"%define stype" goes with "#define YYSTYPE" in C/C++; it was introduced
before dotted names were introduced for %defines.  Note that it is in
principle possible to move from "#define YYXYZ" to "%define xyz" for
this and other preprocessor macros in the C/C++ skeletons.

Paolo