Kevlin Henney wrote:
(Note that the example above avoids the issue of implicit conversion (it won't compile), because it takes the parameter by non-const reference. With the current implementation, this is a good trick to use.)
The main point to take away from this is that this is not a problem ;->
I don't understand the meaning of neither first "this", nor the second "this" :-(
Anyway, there have been several requests for this and thus far no strong opinions against it.
I have yet to see a convincing reason to make it explicit. Autoboxing has been a part of boost::any's design from day 1, which existed before Boost -- and, indeed, the "autoboxing" terminology. Supporting such conversions was intentional. There is no more reason to make the converting constructor of boost::any explicit than there is to make the converting constructor of std::string explicit, or the conversion from int to long explicit, or the conversion from T * to void *, or indeed any other widening conversion.
If we go further, there's no reason for explicit ctors at all? I think that quite the contrary, unless there's very compelling reason why construction should be implicit, it should be explicit, since that's safer.
Of course, there is nothing to stop programmers adopting an explicit style, ie
boost::any bar(1); bar = boost::any(2);
void foo(const any &); foo(boost::any(3));
How is this going to make things safer? I my case I was passing expression of type boost::any to function which took boost::any. Refactoring changed the type, and code suddenly broke. I'm not sure the above would have helped.
The choice is a matter of personal preference, but there is more convenience available in having the implicit conversion than there is safety to be achieved by making it explicit.
That's quite subjective. When conversion to boost::any you actually cross the boundary between statically type-safe code and completely dynamically typed code. Doing that implicitly does not seem good for me. For a better mix of safely and convenience, it's possible to introduce 'reset' method: boost::any bar(1); bar.reset(2);
The important point is that implicit conversions from boost::any should not be allowed, and they never have been.
And that's another question. Conversions *from* boost::any are quite verbose. So why try to make boost::any initialisation concise, if further usage is still verbose? - Volodya