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" 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 (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]:



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