Re: Porting to typed C++ parser (was: Dynamic token kinds)

[Frank Heckenbach]

Hans Åberg wrote:

> >> I might not notice your posts, so do as you wish.
> > 
> > Honestly, you *not* noticing my posts is one of my smallest worries. ;)
> 
> Well, I apologize for replying to your email, but it seemed directed to be.

This one, yes. But so far you have replied to almost any of my
mails, whether directed to you or someone else. Which is fine on a
mailing list, but it makes your "threat" of not noticing my posts a
bit less urgent. ;)

> > There is no conversion, and in most cases, there couldn't be any
> > when types are too different; but even if types are similar enough
> > that a safe automatic conversion would be possible, say char to int,
> > I know of no variant or union that would do so. That's not specific
> > to Bison's variant.
> > 
> > So such a mismatch is an error. The only difference is how this
> > error is handled. std::variant throws an exception on usage; Bison's
> > variant so far basically makes it UB (which is a valid answer; many
> > things in C++ are UB), the current proposal would report an error on
> > construction already, so slightly better than std::variant (in case
> > the mismatching value is silently discarded).
> 
> Two lookup table variations: The values are stored, with the token value, as 
> a pointer to a base class, or as variants.

Looks fine to me. Of course, I'd need to see actual code to say
more, but this change really shouldn't cause any problems as long as
you use the correct types for your semantic values. (And if you
didn't, you would've had other errors before, anyway.) So I think
you should be able to use variants.

I'd probably avoid the pointers and use the classes as semantic
values (within the variant) directly (with move semantics if
possible); then they wouldn't need to be derived from a common base
class (but it doesn't hurt if they are). But again, without knowing
details, this is just a guess.

Regards,
Frank