Date: Sun, 11 Aug 2024 10:47:42 -0400
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
>>
>>>
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
>>
>>>
Received on 2024-08-11 14:47:56