This is the same issue, but it is interesting nonetheless: <AlexDaniel> m: dd (0x0F75.chr x 2).uninames <camelia> rakudo-moar 636a3c: OUTPUT: «("TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL SIGN U", "TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL SIGN U").Seq» <AlexDaniel> m: dd (0x0F75.chr ~ 0x0F75.chr).uninames <camelia> rakudo-moar 636a3c: OUTPUT: «("TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL SIGN AA", "TIBETAN VOWEL SIGN U", "TIBETAN VOWEL SIGN U").Seq»
Note that the order should be normalized. On 2017-07-26 03:36:32, alex.jakime...@gmail.com wrote: > Code: > say (“\c[COMBINING OVERLINE]a” x 2).chars > > Result: > 4 > > > Code: > say (“\c[COMBINING OVERLINE]a” ~ “\c[COMBINING OVERLINE]a”).chars > > Result: > 3 > > > > Both should produce the same result (3). What happens here is “a” on > one side is not being squished into one grapheme with a combiner on > another side. > > Please note that combiners are not the only thing can cause this. Here > is the same thing with ZWJ: > > Code: > my $x = “\x[2695]\x[FE0F]a\x[1F468]\x[200D]”; > say ($x ~ $x).chars; > say ($x x 2).chars > > > Result: > 5 > 6 > > > > > I have a feeling that this is a known issue, and that there might be a > ticket for this already. However, I couldn't find it.