Convenience and automatic conversions.
Users prefer to write this:
sf::Text text("hello");
Rather than this
std::basic_string<sf::Uint32> str;
const char* hello = "hello";
sf::Utf32::fromAnsi(hello, hello + strlen(hello), std::back_inserter(str));
sf::Text text(str);
A compromise would be to wrap this code into higher-level functions:
sf::Text text(sf::ansiToUtf32("hello"));
But one still has to know both the source and target encodings, whereas it is all automatic with the current API.
One has to know the encodings anyway: If you initialize a string with
sf::Text text("hello");
then "hello" has to have the current global locale's encoding. It can't e.g. be encoded in UTF-8 when the locale's encoding is Latin 1 [of course "hello" can, but strings containing special characters probably can't].
But if implicit conversion is desired, sf::String could be used just for this: In function parameters and return values. The library and users are then free to store and use the data as either std::basic_string<Uint32>, std::string or any other type to which a conversion exists. All that's missing is a convenience typedef std::basic_string<sf::Uint32> sf::Utf32String
and sf::String::operator sf::Utf32String() const;
. Then no one has to bother performing string operations on sf::String but can use the full power of std::basic_string -- without API incompatibilities.