tzlaine / parser

A C++ parser combinator library.
Boost Software License 1.0
87 stars 12 forks source link

parsing into private fields #182

Open Jannik2099 opened 3 months ago

Jannik2099 commented 3 months ago

Currently my biggest gripe with Spirit.X3 is that you can't parse into a class with private fields. This leaves you with two options:

  1. use a proxy type, e.g.

class Myclass_impl {
public:
    char c;
};

class Myclass : private Myclass_impl {
public:
    Myclass_impl &base() { return *this; }
};

bp::rule<struct tag, Myclass_impl> rule{"rule"};
const auto rule_def = bp::char_;
BOOST_PARSER_DEFINE_RULES(rule);

void func() {
std::string str{"c"};
Myclass result;

bp::parse(str, rule, result.base());
}
  1. Just don't use private members, which means your parser is no longer a parser, just a validator.

1. makes public headers unreadable as users would have to look into implementation headers to see the actual class body, while
2. violates the parse, don't validate principle and thus allows for invalidly constructed objects that would never be returned from a successful parse.

Are there any plans to remedy this, e.g. via a Boost.Parser helper class that the user class could befriend, or via a specialization that grants access to the private members (Boost.Describe comes to mind) ?

Or am I just missing a workaround that everyone has been using for the past decade

tzlaine commented 3 weeks ago

Uh, no, there are no plans for this. IMO, no library should be writing into your private data members without the purpose of the library being very closely tied to the domain of your type (stl_interfaces::iterator_interface used as an adaptor, for instance).

tzlaine commented 3 weeks ago

Actually, now that I think about it a bit, this might not be a bad idea once we get P2996 in the standard (hopefully, that's C++26). At that point, it might make sense to have an access-granting type that you can befriend, and then just use the reflection machinery. I'll leave this ticket open to investigate that.