Add sf::String::at(), analagous to std::string::at()

[xqbt]

The title has it
That's what happens when you don't follow guidelines 
https://github.com/SFML/SFML/issues/1110

[eXpl0it3r]

What exactly is your use case for this feature?

[xqbt]

The same as for sf::string::at(). Does a range check and throws an exception in case of violation. My use case exactly? Well, I am writing a program that uses SFML and I am drawing out arrays of sf::Strings (and modifying those strings too) and using at() would have already saved me some crashes.

[Nexus]

It's a questionable way of error handling, like checking every pointer against null before dereferencing it, or checking divisors against 0...

Reasonable implementations of the STL (which is used internally by sf::String) provide you with assertions for such cases. They show you all your logic errors when debugging, but you get full speed in Release mode and don't need to clutter code with try-catch blocks, to which you can't even meaningfully react, as the bug shouldn't exist in the first place.

[Mario]

Just as a tiny suggestion. You could just use std::string instead of sf::String for string storing/manipulation.

[xqbt]

Just as a tiny suggestion. You could just use std::string instead of sf::String for string storing/manipulation.

And SFML could do that too, but there's a good reason it doesnt, so I don't either

It's a questionable way of error handling, like checking every pointer against null before dereferencing it, or checking divisors against 0...

Reasonable implementations of the STL (which is used internally by sf::String) provide you with assertions for such cases. They show you all your logic errors when debugging, but you get full speed in Release mode and don't need to clutter code with try-catch blocks, to which you can't even meaningfully react, as the bug shouldn't exist in the first place.

That would be great!
All I am saying is this code should break:

sf::String s("A");
std::cout << s[1] << std::endl;

[Laurent]

And SFML could do that too, but there's a good reason it doesnt, so I don't either

sf::String is mostly meant for automatic conversions, ie. SFML classes and functions take a sf::String so that whatever you pass to them, it ends up in a known encoding. sf::String is not made for string manipulation. So no, because SFML uses it doesn't mean that you have to use it as well. These are two very different use cases.