> From: Markus Schöpflin [mailto:markus.schoepflin@ginit-technology.com]
>
> I don't agree at all.
>

Ok.

> I did think implicit conversions are generally considered dangerous.

Yes, implicit conversions are generally considered dangerous/harmful. Why? Because of introduced ambiguities, and errors; for example resulting in that a function call succeeds (at least compiles) although it shouldn't. To some extent, this can (and therefore will) happen with any, but because of the typical use cases for any, the problem (AFAICT) is not common.

> What is so bad if you have to write
>
> vec.push_back(boost::any(5));
> vec.push_back(boost::any(std::string(", this works!")));
>
> instead?

Actually, I don't think it's bad at all. There's a 5- or 12-character penalty, and changing implicit to explicit adds to the requirements on the client (which I think speaks in favor of the ease-of-use argument) but that's about it. The safety arguments for explicit are obvious.

 
>
> This works because any_print can be implicitly constructed
> from any. Even an
> explicit constructor for any allows this to work.

Absolutely, but you're missing the point - with an explicit constructor for any, the hack would be totally useless; however, for a user who's looking for a solution to a problem it's hopefully worth something.

> >
> > 1) Compiler deficiencies. I gave it a quick try on three
> compilers, and these were the results:
> > * Compiler X didn't care about explicit for templated
> constructors...
>
> So nothing changes for this compiler.

Sure it does. The change makes it easier to write illegal code that works with this compiler.
 
> > * Compiler Y worked!
>
> So something improves (IMHO) for this compiler.

Agreed, if viewed without the context of other compilers.
 
> > * Compiler Z understood the explicit part, but couldn't
> even pass a correctly constructed const any& to functions
> afterwards...
>
> Could you give an example, please?

With an explicit templated constructor for any, on a popular compiler, the following doesn't compile:

boost::any a(5);

std::vector<boost::any> vec;
vec.push_back(a); // doesn't work - cannot convert from const boost::any  etc...

My wording was questionable, as is the error...

I think it would be a big mistake to let compiler deficiencies rule the design of the Boost libraries, equal in size to the mistake of not considering them at all.

The bottom line is this: There's nothing wrong with legal C++ (duh), but unfortunately, reality bites back hard when it means that behavior of a library differs substantially across different compilers. I find that a potent argument although it's a sad fact.

Bjorn