Jiaming: Your paper should have included the following information: Did you show the paper to Victor? Did he like it?  — However, this is a moot question now; see below.

Thank you for doing the background research to find out that P3070R0 "Formatting enums" exists. Its status right now is apparently "forwarded from SG16 to LEWG." It seems to me that the ADL-based mechanism proposed by P3070 would also be able to handle `fpos` — and therefore it should be the mechanism to handle `fpos`, if P3070 is accepted.

Feedback on P3070 itself:

(0) I think Victor is gradually reinventing iostreams. ;) We've now found that `std::formatter` specializations are icky, and are moving to an ADL-callable function in the namespace of the type. All that remains is to rename that function to `operator<<` and we'll be back where we started. ;)  C++ doesn't know how to do customization points that aren't operators (2018-08-23).

(1) Rather than `format_as(x)`, I'd expect the name to be either `format_transform(x)` or `make_formattable(x)`. It fills almost the same niche as C++20 Coroutines' `prom.await_transform(x)`, in that it consumes a not-quite-fooable and produces a fooable. It fills almost the same niche as C++11's `make_error_code(x)`, in that it is an ADL function that consumes a not-quite-foo and produces a foo. We already have these two conventions for naming such functions — `foo_transform(x)` and `make_foo(x)` — we should not create a third.

With that naming change — I prefer `make_formattable(x)` because it's less arcane-looking — I think I would strongly support P3070.

</sidebar>

Now, if P3070 is accepted, then Jiaming's proposal becomes a one-liner in [fpos.general]: