>But do you actually use this? Well, first of all I usually use bison with flex. And I use C++ (i. e. %skeleton "lalr1.cc"). And I use "%define api.value.type variant".
Second, I don't know how to use bison (and flex) the right way. There is a lot of things about bison (and flex), which I don't want to learn now, and which I postponed to distant future. For example, how to use locations, how I should construct semantics values in flex source files (should I use build<...>? or make_ID?), how to report errors, etc. So I just stick with some solutions which seem to work. Say, calling build<...> from flex source seems to work. Okey, let's go with it. When I start new project using bison and flex, I just copy-paste from some existing bison/flex project. Without fully understanding meaning of all this directives (I simply don't remember why I placed all them at the first place). I wish some day I will re-read bison and flex manual and start to use this projects the right way. Yes, I use build<...>. Because it seems to work. Here is my projects using bison and flex: * js-in-cpp-interpreter (well, this is small js interpreter) * pa-0.1 (small proof assistant) * scheme-in-cpp-interpreter (small scheme interpreter) All them are here: https://github.com/safinaskar . I don't need to pass multiple arguments to build/emplace, because I work with simple values such as std::string and int. So, well, yes, I don't need this parameter pack feature. But I wonder why you added this "emplace" method in the first place? Why not stick with "build"? If the only reason was to be idiomatic, then, well, "emplace" should accept parameter pack, because this is what, say, vector::emplace_back does. >Don't you use api.token.constructor instead? I didn't know about it before. But now I checked it, and I don't like it. Because it means I should give names to all my punctuation chars. Thus flex source became bigger. And bison source became bigger, too, because I need to declare all this punctuation chars in it. And I need to keep this punctuation list in bison and flex in sync. >commit 951c88c1d471346f220233ea8839ec42a188062f The commit displays wrong at http://lists.gnu.org/archive/html/bug-bison/2018-12/msg00021.html (but displays properly in my mailbox). The lines are unnecessary wrapped and this makes patch invalid. It seems mailman is misconfigured. I think the right solution is to preserve original line breaks and perform word wrap using CSS only. I think this is how bugs.debian.org did it recently, look here for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771244 == Askar Safin http://vk.com/safinaskar