Robust way to delegate parsing a subset of the parse context

[chiphogg]

Suppose we have a formatter for a compound type, and we implement it with two formatter member variables for the sub-types. We'd like to delegate to the formatter members for both parse and format.

This comment gets very close to what I want, but the parse implementation is only comments. The problem is that I'm finding it very tricky to actually implement what those comments say to do.

To be concrete, aurora-opensource/au#491 was my attempt (specifically, this file). This is extra tricky because I can't take a physical dependency on {fmt} in my zero-dependency library; I have to tell users to inherit their fmt::formatter<Quantity<U, R>> from au::QuantityFormatter<U, R>. But in some ways, that's beside the point, because this would actually work if we had a robust way to delegate the parse functions.

I tried constructing my own parse context object based on the start and end iterators. Abstractly, this feels like the right approach (at least, going based on start and end iterators and then delegating does). In practice, I find that the constructor for the context type varies too much over different versions. In fact, it even seems like it has changed significantly between 11.0.2 and 11.2.0!

What's the preferred, idiomatic way to actually do that parsing delegation? If we have an "overall" parse context, and a start and end iterator for the subset that applies to a member delegator, how can we provide that information to the member? (Bonus points for solutions that avoid needing to take a physical dependency on {fmt}, and that work across a wide range of versions as well as std::format.)

[chiphogg]

Lots of words. I guess what it really comes down to is this.

Suppose we are inside of a parse() call, with some context, and we have some other fmt::formatter specialization we want to delegate to. I want a way to call the other formatter's parse function, given:

• The context object
• The start and end iterators for what that other formatter should pay attention to

[vitaut]

There is no good way of doing this at the moment. You could construct a new parse context but it will not work with argument index tracking. I am planning to look into better support for nested formatters - some work is tracked in #3860.

[vitaut]

Here's what is supported: the enclosing formatter can consume some prefix of format specs and then call another formatter for the rest. This is what range formatter does.

[chiphogg]

Thanks for your response!

I hadn't previously known about nested_formatter. I read up on it a little bit, and it doesn't seem quite like what I want, because I need to delegate to two different kinds of formatter: a numeric one for the quantity, and a const char* one for the unit label. (If it helps, here is the formatter syntax I was trying to support. This was briefly on main, but I had to revert it because the implementation was manually constructing a context to do the delegation.)

Are you open to considering a delegation mechanism like the one I suggested, whereby there is some way to turn a (conceptual) {parent context, start iter, end iter} tuple into a kind of "sub context" that can be passed to the parse function of another formatter? Ideally, I'd like to replace this line with something more like:

        const auto parse_ctx = fmt::make_parse_context_subset(ctx, it, next_end);

[vitaut]

I don't think subcontext will work with automatic argument indexing.

[chiphogg]

Well, that wasn't the answer I was hoping for, but the clarity is helpful!

I think this means I should abandon my "two full-fledged sub-formatters" plan. If I eliminate that, then it seems my best option would be this:

Here's what is supported: the enclosing formatter can consume some prefix of format specs and then call another formatter for the rest. This is what range formatter does.

For a quantity, delegating the numeric part to the formatter for the rep is critical. Users can pick any rep in principle, and we can't know how they'll want to style them. The unit label, though, is just a string (technically, const char[] of a given size).

It's also important to appreciate that in practice, "number right, label left" is going to be the most important justification pattern to support, because this will allow users to align the decimal point vertically for mixed units. In particular, I had been considering the interesting hybrid syntax of nested_formatter, where the width and similar parameters applied to the overall string, but the rest of the format string applies to the sub-formatter (in this case, the numeric type). There's a lot to like about this, but it's not good for quantities because there's no path to aligning the decimals.

So here's my rough plan.

1. For syntax, the format string by default just applies to the numeric part, but we'd allow an optional UXX; prefix, where the XX are digits. This will let the user set the padding width for the unit label. Maybe someday we'd support other options like a fill character or label justification, but I think it makes more sense to focus on the most important use cases; there's no reason to believe anyone even wants more than this.
2. For parsing implementation, we would set our quantity formatter's internal state (which will govern the label) based on the UXX; prefix if there is one, and then call parse on the sub-formatter for the rep type.
3. For formatting implementation, we would format the numeric part, then add a space, and format the label (as const char*). Then, if the user set a width and we haven't consumed it, we would keep adding spaces until we do.

This is mostly just for my future self's benefit. 🙂 But if you see anything goofy or unwise in this plan, feel free to let me know.