LWG-4186 `regex_traits::transform_primary` mistakenly detects `typeid` of a function

[StephanTLavavej]

LWG-4186 regex_traits::transform_primary mistakenly detects typeid of a function

[muellerj2]

More generally, regex_traits::transform_primary() currently implements the general traits requirement in [re.req]/20 and not the specified implementation in [re.traits]/7. Besides the missing comparison with typeid, this also means that diacritics are not properly handled in (most?) non-C locales.

If we want to implement the specification, we should probably add variants of _Strxfrm() and _Wcsxfrm() to the import library that call __crtLCMapStringA/W with appropriate flags for non-C locales (maybe LCMAP_SORTKEY | LINGUISTIC_IGNORECASE | LINGUISTIC_IGNOREDIACRITIC | NORM_IGNOREKANA | NORM_IGNOREWIDTH or something similar).

If we add these new variants of _Strxfrm() and _Wcsxfrm(), we should make sure that their return values are consistent unlike the current implementations of_Strxfrm() and _Wcxsfrm() (#5210).

[muellerj2]

std::locale doesn't actually construct any facets of type std::collate_byname<charT>. It constructs facets of type std::collate<charT> instead. See: https://godbolt.org/z/Te4rcM173

So comparing with typeid(std::collate_byname<charT>) only doesn't make sense. We either have to correct the facets constructed by std::locale (would this break ABI?) or compare with typeid(std::collate<charT>) as well.

[StephanTLavavej]

We either have to correct the facets constructed by std::locale (would this break ABI?)

I don't understand std::locale well enough to say whether it would be binary-compatible. All I know is that std::locale is the most fragile part of the library and changes have had a high risk of damaging it, even back when we could break ABI every major version.