> We can't add a `formatter` specialization in one release and then remove it again in the next.

it won't be removed. format_as doesn't replace a formatter specialization, just simplifies defining it for some use cases.

- Victor

On Sun, Aug 4, 2024 at 1:19 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
On Sun, Aug 4, 2024 at 10:52 AM Victor Zverovich <victor.zverovich@gmail.com> wrote:
Hi Liang and Arthur,

Liang, thanks for working on the paper. It looks good to me, although wording probably needs a bit more work. In particular, you should define the formatter specialization in https://eel.is/c++draft/fpos.

Arthur:

> Would you be willing to take the name I suggested, ADL `make_formattable(x)`, for consistency with ADL `make_error_code(x)`?

I am not sure it expresses the purpose of the function well enough but we could definitely bikeshed in LEWG.

I hope so. Please at least mention the prior art for this kind of function (`make_error_code` and `await_transform`) in the paper, and ideally notify me to be in the room when it's discussed, if you wouldn't mind.

> Would you be willing to roll Jiaming's one-line patch to `fpos` into P3070R1?

P3070 deals with enums only so I don't think fpos belongs there. It is better to go with a separate paper, esp. since it has already been written, and in the future we could potentially switch to format_as.

It cannot "switch" in the future; that's not how the C++ standard library works. We can't add a `formatter` specialization in one release and then remove it again in the next. If we want to be able to format `fpos` at all, we must design it correctly from the get-go.
If you're not willing to roll `fpos` into P3070 as a second application of the new `format_as` mechanism, then my advice to Jiaming will be to rewrite his paper to rebase on top of P3070.

–Arthur