Unicode Blog

As of 2022 the Unicode Consortium will not accept proposals for any new flags. Moving forward, anything with an ISO 3166-1 code will automatically get a flag. The Iraq Kurdistan subdivision mentioned below has a 3166-2 subcode, so doesn't automatically get a flag pushed though. They could've worded it less confusingly, but the rest of the article is quite thorough.

> As a recent example, Kurdistan (a subdivision of Iraq) became an official subdivision in ISO 3166-2 (IQ-KR) on May 3, 2021. The corresponding Unicode subdivision code (iqkr) is slated for release in CLDR v41 on Apr 6, 2022. At that point the flag for Kurdistan will officially be valid — any platform, app, or font could support it. But that doesn’t mean it automatically gets in the queue for everyone’s phone. Only countries with ISO 3166-1 region codes are automatically recommended and require no proposal to move forward.

https://blog.unicode.org/2022/03/the-past-and-future-of-flag-emoji.html

> It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch.

I’d agree, if rustls wasn’t already written, audited and maintained. And there are other examples as well. The internationalisation libraries Icu4c and Icu4j exist, but the multi-language, cross-platform library Icu4x is written in Rust. Read the announcement post on the Unicode blog (http://blog.unicode.org/2022/09/announcing-icu4x-10.html?m=1) - security is only one of the reasons they chose to write it in Rust. Binary size, memory usage, high performance. Also compiles to wasm.

Your comment implies that people rewrite in Rust for security alone. But there are so many other benefits to doing so.

let s = "hello world".to_string();
for ch in s.chars() {
print!({},ch);
}

will iterate through a string character by character. That's the most common use of the "char" type - one at a a time, not arrays of them.

Although the proper grapheme form is:

use unicode_segmentation::UnicodeSegmentation; // 1.7.1
let s = "hello world".to_string();
for gr in UnicodeSegmentation::graphemes(s.as_str(), true) {
print!("{}", gr)
}

This will handle accented characters and emoji modifiers.
A line break in the middle of a grapheme will mess up output.

By the way, open season for proposing new emoji starts tomorrow.[1]

[1] http://blog.unicode.org/2020/09/emoji-150-submissions-re-open-april-2.html

One issue is that most programming languages links their version to a particular unicode version, by example, .NET 4 supports Unicode 5.1 while .NET 4.5 supports Unicode 6, etc.

The new Era will be soon supported by Unicode 12.1 [1].
For older version of .Net (or Java) you also need to support the new Era without supporting the whole Unicode 12.1 spec, introducing a non backward compatibility behavior because the new code point U+32FF has now a different meaning.

Currently we have already added tests for the new code point in all our supported applications and are ready to update them using the same channel as a security issue.

[1] http://blog.unicode.org/2018/09/new-japanese-era.html

> Unicode's mission is to be able to represent all written text. Once you decide that flags should be part of that you kind of have to include all of them.

Unicode has decided flags shouldn’t be part of Unicode.

There are a few flag emoji that got included before they reached that decision and there are “regional indicator symbols” that often get displayed as flags, but that’s it. They won’t, for example, include flags of cantons of Liechtenstein.

See https://blog.unicode.org/2022/03/the-past-and-future-of-flag-emoji.html.