On Thu, 2020-01-02 at 08:27 +0100, Akim Demaille wrote: > > About a year ago, I wrote to you > > > > The thing is that I don't know how people are using these types: > > > they do things that are not documented, and as such, are not > > > considered part of the contract. > > and that's another instance of that pattern.
Obviously. Basically this is another "I think this should be part of the contract" feature request. > which gives me the impression that the real use case would be > something like > > assert(t == token::make_INTLIT(12345)) > > WDYT? Hum. That would require operator==, which would generate a > lot > of code. And it would require the value types to support ==, which > so > far we do not require. It could be another %define option, and then static_assert the presence of operator== for the value types. Or maybe it would be possible to SFINAE it, so that it's available if the indidual operator== are available? Requiring it for all type is sure to break things for some people (or make them write dummy operator== implementations). But anyway, I'd consider that a luxury feature. > The reason I was very happy to get rid of it is that it's kind of > big: Sounds like a good argument. > Have you given a shot at api.token.raw? In that case > symbol_type::token() > would be really thin: it would just return 'type'. Not yet. I'll have to wait until bison 3.5 is everywhere until I get to use it, but it looks good. In fact, is there any reason to ever *not* use token.api.raw when I'm using token.api.constructor? It looks like the symbol_type constructor will (rightly) forbid me from just sticking in raw char values. Should token.api.raw be the default for token.api.constructor? Or at least strongly suggested by the docs? I'll definitely switch to token.api.raw once I'm ready to require bison 3.5. But then, I'd still be using undocumented functions for my unit tests: sym.type_get() sym.value.as<TYPE>() I *should* also be testing sym.location, but currently I don't. So that's my reduced feature request: document and declare those two things (or some variant of them or wrapper for them) part of the public contract for token.api.constructor (at least when used with token.api.raw). > > P.S.: Keep up the good work, bison is my favorite way of parsing > > things > > using C++.... > > Thanks a lot for saying :) Needs to be said now and then. Had to use ANTLR at work, no time for a complete rewrite using bison :-(. Feels like Java. Insists on building a parse tree where I don't need one, which I then need to take apart again to build the data structure that I do need. Keeps converting to UTF-16 and back. Slow. Bison just does what I want, and does it well. Cheers, Wolfgang
