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.
