2
0
mirror of https://github.com/boostorg/parser.git synced 2026-01-19 04:22:13 +00:00

Correct the claim in the docs that if_(c)[p] has attribute type

optional<ATTR(p)>; it actually has attribute type ATTR(p).

Fixes #278.
This commit is contained in:
Zach Laine
2025-10-12 20:40:55 -05:00
parent c32d594d64
commit 9a138a20f6
2 changed files with 4 additions and 5 deletions

View File

@@ -261,9 +261,8 @@ Also, Spirit-style looseness is more complicated than `parser` above
indicates. Remember, `int_ | eps` and `-int_` are supposed to be semantically
equivalent. To do otherwise this would be a profound violation of the
principle of least surprise. So, if they're equivalent, we would need to
apply the same rule to `int_ | eps`. Also, we would probably need to apply it
to `if_(cond)[int_]`, which is also a `std::optional<int>`. This is a lot to
remember, and this is complicated to implement and maintain.
apply the same rule to `int_ | eps`. This is a lot to remember, and this is
complicated to implement and maintain.
I've been using Spirit 1 and later Spirit 2 since they were released. I did
not know about the particular looseness discussed here; a user pointed it out

View File

@@ -319,7 +319,7 @@ the input they match unless otherwise stated in the table below.]
[[ `_if_np_(pred)[p]` ]
[ Equivalent to `_e_(pred) >> p`. ]
[ `std::optional<_ATTR_np_(p)>` ]
[ `_ATTR_np_(p)` ]
[ It is an error to write `_if_np_(pred)`. That is, it is an error to omit the conditionally matched parser `p`. ]]
[[ `_sw_np_(arg0)(arg1, p1)(arg2, p2) ...` ]
@@ -557,7 +557,7 @@ tables below:
[[`_rpt_np_(arg0)[p]`] [`std::string` if `_ATTR_np_(p)` is `char` or `char32_t`, otherwise `std::vector<_ATTR_np_(p)>`]]
[[`_rpt_np_(arg0, arg1)[p]`] [`std::string` if `_ATTR_np_(p)` is `char` or `char32_t`, otherwise `std::vector<_ATTR_np_(p)>`]]
[[`_if_np_(pred)[p]`] [`std::optional<_ATTR_np_(p)>`]]
[[`_if_np_(pred)[p]`] [`_ATTR_np_(p)`]]
[[`_sw_np_(arg0)(arg1, p1)(arg2, p2)...`]
[`std::variant<_ATTR_np_(p1), _ATTR_np_(p2), ...>`]]
]