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.

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

Cheers,
Victor



On Wed, Jul 31, 2024 at 9:45 PM 梁家铭 <liangjiaming_at_[hidden]> wrote:

> Hi,
>
> I haven't shown the paper to Victor since it's my first time to post a
> proposal and initially I think it's the mailing list where we could discuss
> together. But I've mailed Victor for posting a proposal for adding format
> support for fpos and Victor approves me to do so.
>
> Also I agree that we may use a canonical way to express conversion. The
> reason why I still uses template specialization is that:
> 1. There exists specialization for std::formatter<std::vector<bool,
> Alloc>::reference>, which is regulated to be same as formatter of bool. So
> it's not the first try to rely on specialization for conversion in the
> standard :)
> 2. Though for std::byte -> unsigned char, there exists performance loss
> when using specialization instead of ADL-based approach; while as I've
> tested on my machine, there seems no such performance loss (but no gain
> either) on std::fpos -> std::streamoff.
> 3. I mistakenly think P3070 is only for enums (though I know the
> implementation in fmt supports any customization), sorry for that.
>
> So the only advantage for specialization currently is that it doesn't rely
> on the acceptance of P3070. But I don't insist on using specialization, and
> I think it's Okay for me to change the proposal and wording to use the
> approach of P3070. Since P3070 is already forwarded to LEWG, I'm not sure
> whether Victor hopes to add additional illustration for why we need format
> for fpos or just wants me to post another complete proposal as I do
> currently.
>
> Again thanks to you all!
>
> Liang Jiaming
> ----------------------------------------------------
> From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> Date: 2024-07-31 23:39:21
> To: "梁家铭" <liangjiaming_at_[hidden]>,Victor Zverovich <
> victor.zverovich_at_[hidden]>
> cc: Std-Proposals <std-proposals_at_[hidden]>
> Title: P3070 and formatter<fpos>, was Re: Proposal draft for adding
> formatter for fpos
>
> Hi Jiaming, Victor,
>
> 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"
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3070r0.html>
> 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
> <https://quuxplusone.github.io/blog/2018/08/23/customization-point-or-named-function-pick-one/>
> (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] <https://eel.is/c++draft/fpos.general>:
>
> namespace std {
> template<class stateT> class fpos {
> public:
> // [fpos.members], members
> stateT state() const;
> void state(stateT);
> private:
> stateT st; // exposition only
>
> *friend streamoff make_formattable(const fpos& p) { return
> streamoff(p); }*
> };
> }
>
> Victor: Would you be willing to take the name I suggested, ADL
> `make_formattable(x)`, for consistency with ADL `make_error_code(x)`?
> Victor: Would you be willing to roll Jiaming's one-line patch to `fpos`
> into P3070R1? That seems to me like it would kill two birds with one
> stone, and wouldn't cause any additional controversy for P3070.
>
> If Victor says yes to both, then Jiaming gets what he wants, without even
> needing a new paper. :) Of course it ties the fpos improvement to the
> success of P3070 — but I think that's what we want, because we certainly do
> *not* want the STL itself using two different mechanisms for `std::fpos`
> versus `std::byte`. Also, the one-line spec-as-code patch for
> `make_formattable(fpos)` is a lot simpler and more LWG-friendly than
> Jiaming's current proposal's English wording.
>
> Hope this helps (and works),
> –Arthur
>
>
> On Wed, Jul 31, 2024 at 6:57 AM 梁家铭 via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I've finished the draft for adding formatter for fpos (This thread
>> https://lists.isocpp.org/std-proposals/2024/07/10526.php in mailing
>> list). See
>> https://extra-creativity.github.io/public/cpp/proposals/add%20formatter%20for%20fpos.html for
>> it and I appreciate any advice.
>>
>> Great thanks to Victor Zverovich and Arthur O’Dwyer!
>>
>> Liang Jiaming
>>
>
>