Should this work?

[Jacob Carlborg]

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