Hi all,
Sorry for jumping into this so late. I'll send my review tomorrow
(that's still on time, isn't it?). I've been playing with the library
and some questions popped up (please note I've no prior experience
with Spirit):
* What's the rationale for using operator[] for semantic actions
(instead of a regular method like .action())? It looks like the
parsing problem with inline lambdas could be easily worked around with
this.
* What's the rationale for using operator[] for directives?
repeat(24)[p] looks like an over-complication, where a regular
function repeat(24, p) would have just worked fine.
* For non-recursive rules, what's the rationale on preferring the
macro over something like:
constexpr bp::rule
replacement_field { "replacement_field", +bp::char_ };
* My use case involves parsing identifiers that can only contain ASCII
lowercase, uppercase, digits and the underscore. I'd usually do this
by defining a `bool is_identifier_char(char c)` function. This is what
I could do with Boost.Parser - is there a better way (one that doesn't
force me to list all valid characters)?
constexpr const char name_chars[] =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789";
constexpr auto name_continuation_rng = std::span<const char>(
name_continuation,
sizeof(name_continuation) - 1
);
* What's the rationale behind the special naming convention for
functions like _attr, _value, _globals and the like? Is there a reason
why these can't be member functions of the context?
* I've found really frustrating the generic lambda approach for
semantic actions, since this completely inhibits tooling like clangd.
Is there a reason why we can't have a public definition of the parsing
context I could use in my functions?
* I started my evaluation using clang-18 (Linux) but builds fail
(seems to happen under all clang versions I tried). gcc-12 seems to
work fine. Note that I'm using the develop branch, since I understand
it contains the bug fixes for the issues that previous reviewers
found.
Regards,
Ruben.
