Re: [boost] boost::any: explicit constructor?

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 
"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