> 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@gmail.com> wrote:
On Wed, Aug 7, 2024 at 2:09 PM Victor Zverovich <victor.zverovich@gmail.com> 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