Здравствуйте, пффф, Вы писали:

П>Тут проблема — я не могу использовать _Char_traits/_WChar_traits — это же просто детали MSVC реализации.

Правильно, не нужно эти детали реализации использовать.
Нужно просто предоставить свою специализацию шаблона std::char_traits<EMyEnum>, написанную тобой, и с той логикой, которая тебе нужна.

П>Можно было бы написать целиком свою реализацию, но я глянул у MS реализацию _Char_traits. Там оно обмазано всё макросами _NODISCARD, _CONSTEXPR17, _CONSTEXPR20, _HAS_MEMCPY_MEMMOVE_INTRINSICS и тп, ну и по возможности, интринсиками.
П>Хочется, чтобы моя реализация была тоже максимально оптимальной, но тут придётся самому под каждый компилер писать.

Скорее нет, чем да. Тебе не нужно повторять большую часть из того, что там написано. Все эти макросы присутствуют потому, что с их помощью была сделана совместимость со старыми платформами и компиляторами.
Если ты знаешь под какую версию языка С++ пишешь свою программу/библиотеку, то во многих из них исчезает смысл (практически во всех, если это не совсем древняя версия С++).

И на "оптимальность" большая часть из них не влияет. Разве что упомянутый тобой _HAS_MEMCPY_MEMMOVE_INTRINSICS как-то с натяжкой можно притянуть. Да и то, эта конструкция служит больше для оптимизации времени компиляции, а не времени работы в runtime. И вряд-ли ты когда-то свои строки будешь использовать так же широко, как и std::string, чтобы хоть сколько-нибудь заметить эффект.


П>Плюс ещё профит от оптимизации коротких строк.

Учти, что код для нестандартных char_traits протестирован весьма плохо даже в STL.
Вот, например, (ещё непочиненный) баг в libc++: https://github.com/llvm/llvm-project/issues/51158
Конкретно на него со своим перечислением ты вряд ли попадёшь, но если будешь использовать что-то ещё более экзотичное, то появляются риски того, что STL не полностью поддерживает стандарт для таких типов символов.

Здравствуйте, пффф, Вы писали:

П>Тут проблема — я не могу использовать _Char_traits/_WChar_traits — это же просто детали MSVC реализации.

Правильно, не нужно эти детали реализации использовать.
Нужно просто предоставить свою специализацию шаблона std::char_traits<EMyEnum>, написанную тобой, и с той логикой, которая тебе нужна.

П>Можно было бы написать целиком свою реализацию, но я глянул у MS реализацию _Char_traits. Там оно обмазано всё макросами _NODISCARD, _CONSTEXPR17, _CONSTEXPR20, _HAS_MEMCPY_MEMMOVE_INTRINSICS и тп, ну и по возможности, интринсиками.
П>Хочется, чтобы моя реализация была тоже максимально оптимальной, но тут придётся самому под каждый компилер писать.

Скорее нет, чем да. Тебе не нужно повторять большую часть из того, что там написано. Все эти макросы присутствуют потому, что с их помощью была сделана совместимость со старыми платформами и компиляторами.
Если ты знаешь под какую версию языка С++ пишешь свою программу/библиотеку, то во многих из них исчезает смысл (практически во всех, если это не совсем древняя версия С++).

И на "оптимальность" большая часть из них не влияет. Разве что упомянутый тобой _HAS_MEMCPY_MEMMOVE_INTRINSICS как-то с натяжкой можно притянуть. Да и то, эта конструкция служит больше для оптимизации времени компиляции, а не времени работы в runtime. И вряд-ли ты когда-то свои строки будешь использовать так же широко, как и std::string, чтобы хоть сколько-нибудь заметить эффект.


П>Плюс ещё профит от оптимизации коротких строк.

Учти, что код для нестандартных char_traits протестирован весьма плохо даже в STL.
Вот, например, (ещё непочиненный) баг в libc++: https://github.com/llvm/llvm-project/issues/51158
Конкретно с EMyEnum едва ли будут какие-то проблемы, но если будешь использовать что-то ещё более экзотичное, то появляются риски того, что STL не полностью поддерживает стандарт для таких типов "символов".