This issue is not just about the implementation quality, it is actually about the validity of the design.
There are currently multiple layers of misfeature:
char_('Z', 'A') -- should be rejectedchar_(from, to) with non-single code unit param -- should be rejectedchar_("Z-A") -- should be rejectedchar_("あ") -- should be rejected, while char_(U'あ') should be maintainedchar_("abcあdef") -- should be rejected, while char_(U"abcあdef") should be maintained
The real problem is that we can fix x4::unicode but can't do anything about x4::standard and x4::standard_wide.
Non-unicode variants operate on the execution character set, and moreover, our implementation currently uses <cctype>, which utilizes the C locale. So they don't have well-defined meaning for "character ranges" or "character sets".
Note that I used the term "code units", which is the Unicode terminology, merely for explanation, and C locales may or may not be Unicode in practice. Even if some C locale happens to be Unicode, the case like (5.) cannot be resolved for x4::standard because multi-code-unit character like u8"あ" is not representable by the character parser; i.e., (char)u8'あ' is invalid even when char is UTF-8.
This issue is not just about the implementation quality, it is actually about the validity of the design.
There are currently multiple layers of misfeature:
char_('Z', 'A')-- should be rejectedchar_(from, to)with non-single code unit param -- should be rejectedchar_("Z-A")-- should be rejectedchar_("あ")-- should be rejected, whilechar_(U'あ')should be maintainedchar_("abcあdef")-- should be rejected, whilechar_(U"abcあdef")should be maintainedThe real problem is that we can fix
x4::unicodebut can't do anything aboutx4::standardandx4::standard_wide.Non-unicode variants operate on the execution character set, and moreover, our implementation currently uses
<cctype>, which utilizes the C locale. So they don't have well-defined meaning for "character ranges" or "character sets".Note that I used the term "code units", which is the Unicode terminology, merely for explanation, and C locales may or may not be Unicode in practice. Even if some C locale happens to be Unicode, the case like (5.) cannot be resolved for
x4::standardbecause multi-code-unit character likeu8"あ"is not representable by the character parser; i.e.,(char)u8'あ'is invalid even whencharis UTF-8.