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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-26 05:46:10

Kevlin Henney wrote:

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

There's no problem with compiler actually. The real code used "const 
boost::any&", and the typo is only in the email.

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

Because you wrote that exlicit constructor would give more inconvenience than 
safety, and that same subjective judgement can be used in almost all cases. 

The experience in my case is very simple. I had two bugs because constructor 
is not explicit. I've just made it explicit locally, recomplied and got no 
complication errors, so convenience was not hurted. 

> 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'm afraid that I prefer to use number of bugs and number of characters as the 
primary metric, because they don't allow different interpretation.

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

As I've explained, it's not the case.

- Volodya