From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-26 02:36:28
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
> >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 &);
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'
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk