Hi Frank, Sorry, I missed that message. I found it while exploring the mid-rule action fiasco with variants.
> Le 19 juin 2018 à 00:27, Frank Heckenbach <f.heckenb...@fh-soft.de> a écrit : > > Akim Demaille wrote: > >> Well, you can use $<> wherever you want, in regular actions >> too. > > And that's just as unsafe and hiding things from Bison. From the > rest of your mail I now see you want to get rid of $<> completely in > C++. I hadn’t gathered this from your previous mail. Yes, indeed. $<> is really too low level a feature when it is comes to ‘active types’ such as we have in C++ compared to C. So we should not strive to have it work for dubious cases (a type mismatch between the declared type and the one passed to $<>), and allow to not use it (typed mid-rule actions). > Though it does help when moving from C to C++ which I did recently > (though my code was actually C++ the whole time, I had used the C > skeleton before). If I had used $<>, and it was not available in the > C++ skeleton, it would have been another hurdle at this point. In my > case, I'm talking doubly hypothetically; for other users (as the > original report indicates, there are people who use it) it may > become relevant, but some kind of porting guide may help. That’s a good idea. But I’m not sure what it should cover :) >> We tried to eliminate these runtime problems and make them >> compile-time as much as possible. A typical example >> is the symbol constructors in C++, which forbid that in the >> scanner you declare an INT and set yylval->float_val. > > Provided one uses them. Currently, this is not enforced (in fact, > Piotr’s grammar didn't), so not strictly forbidden. And I don’t want to forbid them. And since symbol constructors appeared late, backward compatibility forbids that we require them. Yep I think they are the proper way to do it, so I promote them. > FWIW, I wouldn't > mind strictly forbidding it (maybe by making other constructors > private and adding friends as necessary or whatever is required). If it were to be designed today, I would do that. >> I'm sorry if I gave the impression I would not provide support >> for modern C++, that's definitely not my point. I want to >> avoid _requiring_ it, but, if __cplusplus__ is modern enough, >> we absolutely should support move semantics! I'm focus on this >> issue now just because I'm trying to catch up! And it seems to >> me that it shows we don't need to require std::variant. > > If you're willing to drop $<> completely in C++ (both in mid-rule > and regular actions), it’s probably possible to avoid std::variant. I’m willing to discourage the use of $<> in all the outputs, but forbid them when there’s really no way to support them. > When I did the coding, std::variant actually simplified things for > me (e.g., I could avoid adding move support in Bison's variant > implementation), so if I were you, I'd probably use it even if I > dopped $<>, but if you want to avoid its small runtime overhead, > that seems possible. I don’t think we can afford to simply drop all C++s pre 17. You did wonders with your C++17 skeleton, and it would be great to port your effort in the current framework. Would you contribute to that?