format_as doesn't replace the formatter in a sense that the latter is still
defined (automatically). User doesn't have to define it manually. As I
wrote earlier, you can check the {fmt} implementation to see that the
change is compatible which wouldn't be the case if the formatter wasn't
provided.

- Victor

On Sun, Aug 11, 2024 at 7:47 AM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

> On Sun, Aug 11, 2024 at 10:20 AM Victor Zverovich <
> victor.zverovich_at_[hidden]> wrote:
>
>> > we should do a quick Zoom
>>
>> I don't have time for this but you are welcome to check the
>> implementation of format_as in {fmt} and see that it is compatible with
>> formatter specializations. The next revision of the paper will also cover
>> this. Your example will obviously work, see
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3070r0.html#proposed-change
>> .
>>
>
> Well, that's exactly the example I'm confused about. I had *thought* I
> understood the intent of that example from P3070:
>
> enum class color {red, green, blue};
> auto format_as(color c) -> std::string_view { // [sic]; Arthur proposes
> this ADL entrypoint should be named `make_formattable`, for consistency
> with `make_error_code` and `make_error_condition`
> switch (c) {
> case color::red: return "red";
> case color::green: return "green";
> case color::blue: return "blue";
> }
> }
> auto s = std::format("{}", color::red); // s == "red"
>
> In this example, my proposal would be that the ADL `make_formattable`
> should *replace* `std::formatter<color>`; i.e. there should be no need at
> all for the user to define `std::formatter<color>`.
> The example would Just Work as written.
>
> You say of your proposal, in contrast,
> > format_as *doesn't replace a formatter specialization, just simplifies
> defining it* for some use cases.
>
> That sounds (1) worse, and (2) like the opposite of what the
> std::formatter-less example above seems to be hinting at. So I'm confused
> about what you think P3070 is proposing.
>
> –Arthur
>
> On Wed, Aug 7, 2024 at 11:43 AM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
>> wrote:
>>
>>> On Wed, Aug 7, 2024 at 2:09 PM Victor Zverovich <
>>> victor.zverovich_at_[hidden]> wrote:
>>>
>>>> > 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.
>>>>
>>>
>>> Oh yikes. Then either we should do a quick Zoom so I can figure out the
>>> intent of P3070, or I should bring a competing proposal in the next mailing.
>>> My impression had been that ADL `U format_as(T)` would be a replacement
>>> for `std::formatter<T>` — it would allow a user-defined type `T` to be
>>> formatted using the pre-existing `std::formatter<U>`, specifically so that
>>> the user *would not need* to specialize `formatter<T>` for their own
>>> `T`. For example, this would be a complete and working program:
>>>
>>> #include <print>
>>> namespace Mine {
>>> enum Color { RED, YELLOW };
>>> const char *format_as(Color c) { return (c == RED) ? "red" : "yellow";
>>> }
>>> }
>>> int main() {
>>> std::print("{}\n", Mine::RED); // prints "red\n"
>>> }
>>>
>>> In fact this *seems* to be exactly how it works in {fmt}, so I guess I
>>> don't understand what you're trying to say.
>>> https://godbolt.org/z/esof9Ka76
>>>
>>> –Arthur
>>>
>>>>