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

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2004-02-26 05:07:41

In message <200402261036.28459.ghost_at_[hidden]>, Vladimir Prus 
<ghost_at_[hidden]> writes
>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" :-(

The absence of an 'explicit' is not a problem, and is therefore not 
something that needs a solution. The problem you had was with a 
non-conforming compiler: it is not the job of a library to fix all the 
breakages in a compiler. Sorry for not being clearer.

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

Of course not, please don't exaggerate. If you read my email and take 
the time to study more carefully the role that conversions play in the 
language you will appreciate that 'explicit' is a powerful and useful 
tool that is intended to disable implicit conversions where they are 
harmful and meaningless. I cannot see how you would "go further" to 
reach your conclusion.

Many programmers fail to distinguish between narrowing and widening 
conversions, and arrive at unnecessarily constraining guidelines as a 
result. Conversions play a role in supporting the concept of 
substitutability, which is a significantly broader concept than the 
conventional application of LSP in OO might lead you to believe.

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

That may be a guideline that some C++ programmers have chosen to follow, 
but it is unnecessarily strict and not really in the spirit of the 
language, IMHO. That is their preference, and there is nothing in wrong 
in having such a preference, but it is not a preference that 
boost::any's design enforces.

Implicit conversions should only be supported where they are safe and 
have a strong semantic and transparent correspondence, so where there is 
some notional substitutability between of source type wrt the target 
type, eg int to long, derived pointer to base pointer, any value to 
boost::any. A stricter guideline does not buy you any more real safety 
and it is inconvenient for the common case, so I cannot see why it would 
be a reasonable design goal.

So, by and large, single-argument constructors should be 'explicit': for 
entity types, function object types, exception types, etc this is pretty 
much a rule; for value types it is a consideration or recommendation, 
but not a blanket rule.

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

You were using a broken compiler: that was the root cause of the 
problem.

>For a better mix of safely and convenience, it's possible to introduce 'reset'
>method:
>
>       boost::any bar(1);
>        bar.reset(2);

Ugh. No. That again misses the point and transparency of value-based 
programming. C++ is a language that has good support for value-based 
programming. It can support meaningful conversions and restrict 
meaningless ones, at the discretion of the programmer. If you want Ada, 
you can Google for it ;->

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

Again, if you study the nature and role of conversions in more detail 
you will see that your conclusion does not follow. Not all kinds of 
conversion have the same weight and consequences, and they should be 
treated accordingly: narrowing conversions are potentially dangerous, 
and need to be marked in code; widening conversions are not, and do not.

HTH

Kevlin
-- 
____________________________________________________________
   Kevlin Henney                   phone:  [phone]
   mailto:kevlin_at_[hidden]     mobile: [phone]
   http://www.curbralan.com        fax:    [phone]
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________