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@gmail.com> wrote:
On Sun, Aug 11, 2024 at 10:20 AM Victor Zverovich <victor.zverovich@gmail.com> 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@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.

–Arthur