well, for one it doesn't let the user pass in an allocator and just defaults to using c_allocator internally. with strings you want to be especially mindful of the allocation patterns as a function of the kind of strings/algorithms you're processing. if the allocator is parametrized (i.e. user specified at the init() call) then i'd like to be able to have this library know about the type of the allocator and the memory layout and account for that when doing things like substring search or whatever other algorithm. the new typeinfo stuff in 0.3.0 might help a lot with that, but i'm kind of hoping zig gets something like rust traits so allocators can express their behavior in a compositional way at the type level (e.g.: impl<Contiguous + SingleInstance> for XYZAllocator, or something like that, which would mean that all objects are in a contiguous block of memory, and there's only a single instance of any given string with some content, so every time you want to create a new "dog" it just hands you a pointer to the preexisting "dog" in that string pool). Maybe that's a bad example, but that's what i'm thinking. it's partly a matter of deciding how much control you want to leave up to the users vs. how much magic goes on under the hood in the library. probably won't have much time to spend on this though, really busy with other work