Artyom wrote :

...

So you do not consider the fact the following code compiles (and

runs!)

...

cleanly as a painful problem?

std::string s = get_utf8_string(); s[42] = '?';

It is fine code. Why? Because if you assign s[42] you probably know why you are do it and you most likely know that there is a some ASCII character there.

I want more safety. And opacity is one way to it. I consider that stating "The code is OK because you know what you're doing" is an offense to all safety efforts put into C++ and its standard library. Sorry for the tone, but I failed to express my views in another way. Non throwing failures somewhat disturb me. Especially if you can design a failsafe interface.

...

I consider that std::string is cool as an internal for a Boost.Locale implementor, not as a standard API for encoded strings that should be used by all C++ developpers.

Seems to me you hadn't seen Boost.Locale code and what does it does.

I've seen it and toyed with it, and it's great. I have no problem with Boost.Locale, I have a problem with all the mess than can be done with the string type it has to publicly use today. And by the way, you're the one who stated that encoded string processing should be done by a domain expert library. I'm only exspecting you to translate this into : we need a more opaque string. Ivan