[roca]

The problem is that safety means, by definition, ruling out unsafe code at compile time or run time. If you don't prioritise safety early then you run a high risk of discovering when you try to retrofit safety later that you need to rule out a lot of existing code. Even if you haven't promised stability, breaking existing code hurts the ecosystem.

Therefore when setting priorities for language evolution it seems better to identify work that is less likely to result in breaking code, and prioritise safety over that.

[kristoff_it]

Your are correct, yet general statements. The situation in the Zig ecosystem right now is not one based on "retrofitting" security into the language, but, if today we don't have a function that sanitizes utf8 in the standard library, that doesn't mean that the language is going to become a swiss cheese in terms of security.

Please read Andrew's answer and check the linked project management dashboard on GH.