Parsing::define(OPCODE, OPERATOR)

[xparq]

Well, but its only benefit compared to

CONST_OPERATORS[opcode] = [](Parser& p, size_t pos, const Rule& rule, OUT size_t& len) -> bool { ... } 

seems to be that it can check if it's been set already.
And perhaps that the [CONST_]OPERATORS map can be hidden, can also be considered an advantage, but it's a stretch...

OTOH:

• If really checking for existence (instead of overriding), errors would need to be handled by callers...

• Also, custom OPCODEs would probably still need to be defined symbolically -- somewhere... --, to be practical for actually defining grammar rules. :-/

• Use it in init(), and also in test/extending!

• But, again, there should be two sets: one for const, another for non-const, right? What does C++ do nowadays with Function types differing in c-v only?
  ! Hehh, congratulations!... :) It doesn't accept a param. with a c-v mismatch, yet it refuses to dispatch on it, so: "ambiguous call" to define, if trying to overload it based on the c-v diff... The good old begin/end cbegin/cend crap, still...

  • Leaving it commented out for now.