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
>