Luvit 2.x provides the ustring library, which is a pain to use as it uses wrapper objects resulting in a lot of unnecessary overhead. Luvit 3.x is a good time and place to decide whether extra UTF support can be dropped entirely (LuaJIT's utf8 module can work in a pinch), whether to continue with ustring (which I'd rather not), whether to adopt a different library altogether (perhaps baked into luvi itself? I've heard some UTF libraries can act as replacements for the standard utf8, but I'm not sure we want to do that), or write our own from scratch.
Luvit 2.x provides the
ustringlibrary, which is a pain to use as it uses wrapper objects resulting in a lot of unnecessary overhead. Luvit 3.x is a good time and place to decide whether extra UTF support can be dropped entirely (LuaJIT'sutf8module can work in a pinch), whether to continue withustring(which I'd rather not), whether to adopt a different library altogether (perhaps baked intoluviitself? I've heard some UTF libraries can act as replacements for the standardutf8, but I'm not sure we want to do that), or write our own from scratch.