Nikita Kniazev

No, actually I have showed above that `hold` on general usage is way more expensive (even if we assume zero cost move) as it requires heap allocations. I will try...

> That would be a either a breaking change If it will remain a `no-op` or optimization guide it will not. Otherwise I have said a deprecation cycle so users...

And you may also specialize empty trait so empty call on your type will be no-op.

> I think you are comparing always using `hold` to the new solutions. You misunderstood me. The behavior of alternate parser for variant types and values of non-container types will...

You simply do not need to `hold`/clear a non-container attribute because it will be rewritten in any other successful branch entirely. So call `empty_if_container` will become `no-op` on non-container attributes...

> Not sure I understand. 'hold' is explicit. And typically, you do it with containers. If the user has 'hold' on non-container attributes, then he asked for it. Yes, he...

> Yes, he may have asked this, but he actually may misused it. Without semantic actions it does not change parsing result at all. This is also apply to a...

> For example, Spirit "classic" has been deprecated for more than 10 years now, yet it persists because, people use it and boost libraries use it. removing it now will...

Ok, it looks like `hold` manual optimization 2 could be done automatically, so I do not see not a single advantage of manual `hold` placing. Update to first post: -...

Well, I have no comments here... ```cpp #include #include #include #include "../spirit/test/x3/test.hpp" int main() { using spirit_test::test_attr; namespace x3 = boost::spirit::x3; { std::string s = "z"; auto a = x3::rule{}...