The most common problem that
explicit
patches is automatic conversions when you call functions. Say you have a function, f, that takes one of your
circle
objects:
void f( circle do_it_on_this );
Most of the time you'll call it with a fully constructed
circle
:
circle c( 100 );
f( c );
However it also means that a call like:
f( 100 );
will also work. This can have the unhappy side effect of confusing the programmer who wrote the code into thinking that f has an integer overload when it doesn't. In your question you seem to be asking why on God's earth anyone would design a programming language that allowed this form of implicit conversion in the first place. If C++ didn't implicitly convert then we wouldn't need
explicit
to disable it.
There are two main reasons this occurs. The first one is compatibility with code written since the year dot. There's loads of code out there (especially stuff written before C++98 compilers were readily available) that were written expecting implicit conversion. Some of this code should never have been written but that's really easy to say in hindsight. If the standards committee had reversed the behaviour (e.g. by introducing an implicit keyword) then there's a lot of code out there that would stop working and need a significant amount of work to get working again.
The second one is that implicit conversion is actually useful in some cases. If used carefully it can reduce the amount of overloads you need and help get rid of nested statements that would make a Lisp programmer wet themselves. Numeric programmers like this sort of thing a lot as they can use built in types and handrolled numeric types and, by using a converting constructor, can eliminate one set of overloads from the operations on a class. With implicit conversion you don't need to litter your code with things like:
f( big_int( 87 ) );
or have to write forwarding functions like:
void f( int n )
{
f( big_int( n ) );
}
which can gum up overload resolution as most people don't understand the rules by which overloads and overrides are selected.
[Another example is the tradition of using string literals where you should be using strings so you can write things like:
f( "It's all gone horribly wrong" );
instead of:
f( std::string( "It's all gone horribly wrong" ) );
without having to specify two overloads of f.]
Anyway, I hope this lot puts the feature (feel free to add quotes around the word if you don't think it's a feature but a bug that's hung around) in context. If you get a chance have a look at "The Design and Evolution of C++" by Bjarne Stroustrup. It discusses some of the design issues that had to be considered around
explicit
from the point of view of one of the people that had to keep things working during standardisation.
Cheers,
Ash