RE: Enhancement request: enabling Variant in C parsers

[Victor Khomenko]

Hi Akim,

> That’s a matter of style, and I disagree.  Sure, it’s _needed_ for decltype on
> incoming arguments, but it’s also just the right thing.
> C was wrong, and is still wrong about arrays, pointers, and functions.
> Even Go people, who are clearly the real heirs of C, have departed from C
> on these three concerns.
> https://blog.golang.org/gos-declaration-syntax
> 
> However, if you _really_ think it makes the example harder to understand, I
> will change it.  But they, don’t come up again with ostream_iterator :)


Well, when in Rome do as Romans do... This chapter is for C/C++ programmers, 
not Go. Some of them are not even familiar with the new syntax. If you check 
cppreference website, they don't use trailing return types unless absolutely 
necessary.

On the philosophical note, I understand the reasoning in the blog you 
referenced, but I think it misses several important points. In its time, C blew 
other imperative languages out of the water, and one of the reasons was its 
conciseness. Trailing return types require two extra tokens, "auto" and "->", 
so most people will prefer the old syntax unless the trailing return type is 
the only way to declare a function. Yes, the syntax can get ugly sometimes, 
e.g. the blog uses a pointer to a function returning a pointer to a function as 
an example. It’s ugly indeed. However, let's do a reality check: how many times 
in your whole life did you need to declare a pointer to a function returning a 
pointer to a function? 0? 1? 2?!! So a very marginal case is used to prove a 
general point.


> >  * It is possible to use flex with C++ streams - flex has C++ interface, 
> > and I
> think C++ parsers should deploy C++ lexers.
> 
> Yes, but again, it’s a tutorial about Bison.  Flex in C++ is a moving target
> (Hans, that’s your cue :-), and I’m not sure I should show too much about it.

It's not "too much", it's about replacing a C scanner by a C++ one - which I 
guess more natural for C++ parsers. BTW, the C++ interface in flex was around 
for a while, and not that unstable - at least some of my C++ scanners are older 
than a decade ago and they still compile...


> > Another thought for future: You mentioned that AST with location
> information is in fact the mainstream, but this is never explained in the
> manual!
> 
> We don’t speak much of ASTs either :)  I don’t think that’s our job here.
> Don’t you agree?

So you assume users already know that trick with locations? Wow!!! You must 
have some really brilliant users, I feel so inadequate ;-)

Well, seriously, a bison parser interfaces the world in two places: On the low 
end, it uses a scanner, often a flex one. On the opposite end, it usually 
generates an AST for further processing. I believe these two interfaces deserve 
to be covered in some detail, otherwise users will be reinventing the wheel. 
(IMHO)

Cheers,
Victor.