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

Cheers,
Victor

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