Matus Chochlik wrote:
Dear list,
Then it was proposed that we create a utf8_t string type that would be used *together* (for all eternity) with the standard basic_string<>. While I see the advantages here, I (as I already said elsewhere) have the following problem with this approach:
Using a name like utf8_t or u8string, string_utf8, etc. at least to me (and I've consulted this off the list, with several people) suggests, that UTF-8 is still something special and IMO also sends the message that it is OK to remain forever with the various encodings and std::string as it is today.
rather than viewing std::string as a sequence of character encodings, view it as a sequence of bytes along with a few extra functions compared to std::vector. Lot's of programs use std::string in this way without depending upon any behavior related to character encoding. now, consider utf8_string as a sequence of character encodings which might be implemented in terms of std::string. It's a different thing and should have a different thing.
We should *IMO* endorse the opposite.
It is not our proper role to endorse or deprecate programming practices. It's a fools errand in any case. The best anyone can do is provide alternatives and explain why he thinks they are superior.
My suggestion is the following:
Let us create a class called boost::string that will have all the properties that a string handling class in 2011+ A.D.
What happens in 2021 A.D. when it is discovered that "they did it wrong".
should have, basically what std::string should have been.
what you (or we, or someone else) thinks string should have been. This idea depends upon a few presumptions which are not true. a) that std::string is used only for character encodings. b) that someone can know all the things that std::string might be used for as it is c) that someone now has the knowledge to design a new version of std::string which will never need be changed. Basically, if you're going to make a "new" thing - fine - just make sure you give it a new name. Robert Ramey