On 2014-01-10 02:06, Manu wrote:
Then there's probably a fundamental problem somewhere, and it should be re-thought at a lower level. Perhaps even something super simple like a can't-go-wrong naming convention, that makes it REALLY plain when string related function are dealing with bytes, codepoints, or graphemes?
Isn't it with convention that every thing _can_ go wrong.
It would seem to be that a lot of the confusion and complexity surrounding strings is because it tries to be 'correct' (and varying levels of correct in different circumstances), but there are no clear relationships between different functions that deal with these different versions of 'correct'-ness.
I think the confusion comes from strings are just plain arrays, which are also containers. If there's a function that works on containers it will work on arrays and strings as well. Because of that it's put in a general module for containers, in this case std.algorithm. Functions that work on arrays will also work on strings and they're put in the most general location they fit, std.array. Functions that work only work on strings are put in std.string. The we of course have some other modules, like std.uni and std.utf making it a bit more complicated.
I suspect your effort is not uncommon. Is this not clear evidence of a critical problem?
Probably. I find that to be a problem in most standard libraries. They have very general functionality but very few convenient functions, that require calling two or three functions and perhaps creating an object.
-- /Jacob Carlborg
