On Sun, Aug 4, 2024 at 10:52 AM Victor Zverovich <victor.zverovich_at_[hidden]>
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