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
