> 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_at_[hidden]>
wrote:

> 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
>