Hans Åberg wrote: > > By default, I keep recipients (list) and CCs (Akim) as is. > > With a reply to all, it would come out right.
Depends on what you consider right. It's a mailing list. Those who write here are expected to read via the list (subscription or archive; I know you do) or take their own measures (Reply-To or CC). With "reply to all", I get all of your mails twice, doesn't seem right to me (though only slightly annoying these days, as opposed to 20 years ago when every KB of internet data cost a fortune ;). > > If you > > want a private copy, set a Reply-To. > > Those are generally bad. I don't agree. Some years ago there was a somewhat famous rant against them, but it was full of BS and misunderstandings. Or you can set a CC to yourself if you wish. > I might not notice your posts, so do as you wish. Honestly, you *not* noticing my posts is one of my smallest worries. ;) > >>>> Actually, I pass the semantic value through a class object to > >>>> which the lexer function belongs, so the extra arguments are not > >>>> needed. So I must think more about this. > >>> > >>> FWIW, my lexer function is also part of a "driver" object, but I > >>> don't think that's relevant here. Maybe you think of the "%param" > >>> arguments, but it's not about those. > >> > >> No, I use the Flex C++ parser right now, which for some reason > >> requires an empty argument, so this works without patching the > >> header, that is, until they decided to bomb it in 2.6 and later. > > > > I don't use flex anymore, and never used flex C++, so I don't know > > about that. But again, that's unrelated to the current proposal. > > It was in response to your comment. Which was in response to your comment about some mysterious "extra arguments". > There might be a problem with the Bison variant if one in the > lexer returns an object of another type that the token type, and > expect a conversion. 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). Regards, Frank
