Why does string support `operator=(char)`?

Question

A colleague of mine today uncovered a very subtle bug in our code, which basically went like this:

double d = 65;
std::string s = "Hello world";

// .. somewhere later, accidentally assigning to s instead of a similarly
// named numerical variable.
s = d;

// s is now 'A' 

The reason that this bug can occur, I found, is that std::basic_string<_Elem> has an assignment operator

_Myt& operator=(_Elem _Ch)
{ // assign 1 * _Ch
  return (assign(1, _Ch));
}

Now the compiler doesn't really complain (a lot, it emits a warning about the narrowing conversion if the level is sufficiently high). It seems we caught this bug early enough that it did not do a lot of damage, but I was wondering why this is allowed. After all, I cannot write

std::string s = 65;

because std::string does not have a(n implicit) constructor which takes a char. Wouldn't it be safer to make it an explicit conversion which forces you to write

std::string s = string('A');

and that would prohibit assignment to a single _Elem (char).

Is there any reason this assignment operator was provided? As the same colleague correctly noticed,

double d;
char c = d;

is allowed whereas

int* p = d;

is not (for any pointer size) - presumably because the implicit conversion from number to pointer is deemed dangerous. In fact, it even seems to have made it into C++11 which, as far as I have seen, tries to be quite strict and helpful in data type management.

Answer 1

Somebody 30 years ago who wrote the library from which std::string was imported thought it was a good idea.

Before standardization it was not removed.

Since then, removing it would risk breaking legacy code, which is a cost.

The deprecated attribute was only added recently to C++, which allows a standard way to tell the user of a function that it will go away shortly. Nobody has managed to make it deprecated, which is a sensible step required before it would be removed (just removing it would be rude). I encourage you to make such a proposal.