If we don't want to go with the approach because it involves too much boilerplate, another approach would be to go back to what we were doing before, where we raise the Layout class outside of the memory-representation class and put the serialization on the Layout class. One of the problems now is that there are some cases where the deserialization is conditional, or we have to extract some bitfields to convert to the in memory format, so there's always a little bit of custom marshalling involved.
If we wanted to more easily generalize the deserialization, limiting it to the layout classes could provide better code reuse since you may be able to declare the layout classes declaratively with macros and then have a single deserialization function that is templatized and works for everything due to the declarative nature of the layout classes. Then you could have the in memory representation classes take a layout class to the constructor or something.
Either way, I don't think this is a bad first step, and I plan to generalize as much as possible using variadic templates in a followup patch.
This should be return parseError();, and if we were really cool we'd propagate out the Error. I'm fine with the existing bool.