Re: [Discussion] Should All S tring Functions Become Multi-Byte Safe?

On 17 August 2024 00:25:13 BST, Mike Schinkel <mike@newclarity.net> wrote: >I am not sure I agree with you that adding Unicode support is the wrong angle, per se. > >A strong argument could be made that Unicode support is a necessary but not sufficient building >block for "internationalization support." IOW, if you want to get to the latter it is >probably a lot easier to start with the former as the scope of the latter is by-nature larger. After >all, perfect is the enemy of the good and waiting for a full-press effort for internationalization >support could well push off Unicode support long down the road. Again, that's not really what I intended to say, but I'm probably not expressing myself clearly. I was thinking about the way we frame the conversation, the words we focus on, and how that shapes the conversation. The example that keeps coming to mind is password_hash/password_verify. It seems to me that for years, the conversation was framed around "cryptographically safe hashing functions", and teaching users why and how to use powerful but confusing functions like hash() and crypt(). Then it got reframed from the point of view of a web developer wanting to implement logins, and we ended up with fantastically easy to use functions. In the same way, I think "Unicode support" should be the awkward background work that we do *because we're trying to solve specific problems involving text*. In the case of this thread, I think the actual user story is "I want to allow users to enter a wide range of characters, but restrict them in contextually appropriate ways to ensure various types of safety and security". The implementation of that involves a lot of technicalities about how Unicode works, but ideally we want to find meaningful abstractions of those technicalities, not just require every user to understand them. (PS I think I accidentally called you Rob just now; sorry!) Rowan Tommins [IMSoP]