Generally, please calm down. I am not attacking you personally. I am just discussing, weather implicit conversion might be a good idea as an additional way to execute string factories. My current opinion is, that it is not my preferred interface, but as an additional option, why not? Only those, who use it, pay for it.
Sorry, if I seem upset. :/ It is true that this point annoys me a bit, because I really think that the case against implicit conversion has been well made. Nevertheless, I believe in discussions as a device to exchange knowledge, so…
Why do you think the standards committee added explicit operator <type>() to the language? They don't do these language changes for fun.
They also added the possibility to create implicit type conversions. If implicit conversions really are so bad, as you put them, why did they do that? For fun? Were they drunk?
People learn from mistakes. There was a time when they (the standard committee) thought that implicit conversions are great, until they discovered that implicit conversions lead to subtle and dangerous bugs. They undermine the idea of discovering bugs at compile time rather than at runtime. If you find the one example given by Herb not convincing - although it is nicely down to the point -, please go ahead and read the references given in the article, from Scott Meyers and others, where you will find more.
And I really dislike explicit type conversions. Every time I had considered to write an explicit type conversion, a member function, or a free function with a speaking name was the better choice. So if we come to the conclusion, that the implicit conversions harms anyone, but those who use them, I'd vote for no conversion operators at all. Use the explicit member functions then.
There are also things I dislike, but personal preference should only help you make decisions when the case is ambiguous. Most of the times, there are good arguments for one side, and then - because you don't write a library for yourself, but for a potentially large group of people - it is just rational to put the needs of others before your own preferences. "The needs of the many outweigh the needs of the few or the one", as someone famously said. Consistency is very important. Consistency with the standard library. Consistency with contemporary use of C++. Consistency with other boost libraries. Consistency helps one to grow an intuition how things work, which in turn reduces the number of times that you have to look up stuff in the reference manual. Python is very good at this and it this is one reason why it is so popular. I think it is intuitive if you allow an explicit conversion to string for a string factory. If people don't use it, fine, no harm done.
Also, if you won't take it from us, please go and take the wisdom from Herb Sutter http://www.gotw.ca/gotw/019.htm http://www.gotw.ca/gotw/019.htm "It's almost always a good idea to avoid writing automatic conversions, either as conversion operators or as single-argument non-explicit constructors."
It is almost always a good idea to listen to the wise people and then think for yourself, if what they say really fits to your situation. [Christof Donat, just now]
How does it not fit your situation?
I totally agree with him. Explicit type conversions are ugly as hell, and it is good, that way. Implicit type conversions might be dangerous, so we should think twice, before we add them. But if in this case they don't hurt anyone, then I think there is no good reason to not add them.
Explicit type conversions will not hurt anyone, implicit type conversions might. Hans