+1
Especially an enum doesn't have any private data members so we don't need access to private data members; hence there is no need for member functions.

On March 12, 2025 2:39:15 a.m. EDT, "Robin Savonen Söderholm via Std-Proposals" <std-proposals_at_[hidden]> wrote:
>I paraphrase Mateusz Pusz from one of his courses: prefer free functions
>over member functions.
>ADL is a thing in C++ and I see no benefits of this proposal vs to utilize
>ADL and just define a free "to_string"-method in the enclosing namespace.
>Free functions found with ADL are just as much part of a types API as their
>member functions.
>
>// Robin
>
>On Wed, Mar 12, 2025, 06:47 Simon Schröder via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>>
>>
>> > On Mar 12, 2025, at 2:23 AM, Dmitrii Shabalin via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>> >
>> > If you have any idea how to have a function inside in the enum, please,
>> share your idea with an example.
>>
>> My first thought was that instead of allowing enums to have member
>> functions I would put an enum inside a class:
>>
>> class Test
>> {
>> public:
>> // not en enum class on purpose!
>> enum TestEnum { test_value = 0 };
>>
>> static string_view to_string(TestEnum);
>> }
>>
>> Declaring a variable is slightly more to type:
>> Test::TestEnum e = test_value;
>> and you can‘t call it as a member function:
>> e.to_string(); // not possible
>>
>> However, the “member function call” could be solved differently. We could,
>> once more, try to allow for member call syntax to also look for “free
>> standing” (or otherwise scoped functions) that take the type as the first
>> parameter. (With this solution it doesn’t really matter if we put the enum
>> inside a namespace or class.)
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>