Hi,


I finally decide to use specialization in the initial proposal since it's more like a bug fix for std::print and may be improper to delay to the next epoch. But I cherish Authur's advice too, so I decide to post another proposal to change both `vector<bool>::reference` and `fpos<T>` after Victor decides to extend P3070 to all user-defined types in the future (or Victor may change them directly in the future proposals), possibly in C++29. If LEWG thinks it's better to delay to C++29 instead of shifting together with `vector<bool>::reference`, I'll rewrite it in the future revisions of the proposal. This is the current version: https://extra-creativity.github.io/public/cpp/proposals/add%20formatter%20for%20fpos.html


That's a hard decision for me. Thanks to you all!


Liang Jiaming
---------------------------------------------------------------------
From: Arthur O'Dwyer <arthur.j.odwyer_at_gmail.com>
Date: 2024-08-05 04:19:42
To: Victor Zverovich <victor.zverovich_at_[hidden]>
cc: "梁家铭" <liangjiaming_at_stu.pku.edu.cn>,std-proposals <std-proposals_at_[hidden]>
Title: Re: P3070 and formatter<fpos>, was Re: Proposal draft for adding formatter for fpos
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