RE: Enhancement request: enabling Variant in C parsers

[Victor Khomenko]

Hi Akim,

Nice to hear that there has been a lot of progress! I'm a bit overwhelmed with 
teaching and other stuff, but will try to read this carefully in the next few 
days.

Some quick reactions:

  * My 8 parsers are in the same codebase, which comprises several static 
libraries and several executables. One of the libraries has multiple parsers, 
and the executables depend on several libraries with parsers, and some 
executables have their own parsers. Most parsers are simple, only a couple of 
non-trivial ones. There is some weird code, e.g. one file format is almost 
regular, but allows expressions in certain fields, so it's read by a flex 
scanner that calls a bison parser to parse those expressions (in the hindsight, 
I should have implemented this top-level scanner as a part of the parser, but 
then I would not be able to spin it as "thinking outside the box").

  * The new simple example is most welcome!

    ** No need to implement to_string() in the simple example, better use 
https://en.cppreference.com/w/cpp/string/basic_string/to_string

    ** You could use
              std::copy(v.begin(), v.end(), 
std::ostream_iterator<char>(std::cout, ", "));
         to print out a vector of strings.

  * "virtual ~calcxx_driver()" in the version of bison manual that I had used, 
but this line was removed in the version you sent, so ok now.

  * In Sect 10.1.2 it would be good to mention that location.hh can be 
suppressed (it's explained only later in the text).

  * Maybe it would be better to have an api flag to suppress/request the 
generation of position.hh and stack.hh? %require "3.2" doesn't seem the right 
way of doing this, IMHO: The users may want to use %require "3.2" for but still 
need these files for compatibility reasons.

  * The trailing return type for function definitions, like
        auto to_string (const T& t) -> std::string
     is a bad style - this syntax is intended for situations when the return 
type of a template function depends on the parameters, e.g. 
               template<class T>  auto plus(T a, T b) -> decltype(a+b){ return 
a+b; }
     In other situations, the traditional syntax should be preferred.

  * It is possible to use flex with C++ streams - flex has C++ interface, and I 
think C++ parsers should deploy C++ lexers.

Another thought for future: You mentioned that AST with location information is 
in fact the mainstream, but this is never explained in the manual!

Cheers,
Victor.