In message <200402261036.28459.ghost@cs.msu.su>, Vladimir Prus <ghost@cs.msu.su> 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: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

In message <200402261346.10248.ghost@cs.msu.su>, Vladimir Prus <ghost@cs.msu.su> writes

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

In which case you got advertised behaviour, just not the behaviour that you expected :->

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

Inconvenience has both a subjective element and an objective element. One aspect of convenience in boost::any is that because it can hold any value -- as its name suggests -- it does so, and does so as transparently and consistently as possible. It is safe, in exactly the way that void * isn't, but that does not mean that all accidental misuse is prevented or preventable -- even though it is type safe, there is still an element of placing trust in the programmer.

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.

I outlined in a previous email the intended syntax for use. To break this would be more than a little inconvenient, and certainly against the spirit of its design. Making the constructor 'explicit' would break the compilation of other code that is quite reasonable -- perhaps not yours, because you are following the style I outlined as an alternative in a previous response -- but it would still break it and for no good reason, eg std::map<std::string, boost::any> table; ... table[key] = 0; // reasonable usage Making the constructor 'explicit' will still not trap all occurrences of the type of error you made: class variable { public: boost::any &value(); ... }; void do_something(const pair<std::string, boost::any> &); ... variable foo; do_something(std::make_pair(key, foo)); // oops, should have been foo.value Given that you cannot trap all of the errors all of the time, the question then becomes where should the compromise be and what are the trade-offs? I favour the current situation for a number of reasons, including transparency of use, which I cited as a motivating convenience, and consistency. It is also entirely possible that you could reconsider the interfaces or style of design that led you to arrange your interfaces as you did. Sometimes such usage errors point to other areas of design tension.

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.

I am happy to use this metric as well, but you will find that it is not free of interpretation. However, be aware that it is not a metric of either safety or convenience: it is a measure of bugs and the number of characters. When and how did your bugs manifest themselves? Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

In message <001901c3fc77$64c7cf70$1d00a8c0@pdimov2>, Peter Dimov <pdimov@mmltd.net> writes

Kevlin Henney wrote:

...

I outlined in a previous email the intended syntax for use. To break this would be more than a little inconvenient, and certainly against the spirit of its design. Making the constructor 'explicit' would break the compilation of other code that is quite reasonable -- perhaps not yours, because you are following the style I outlined as an alternative in a previous response -- but it would still break it and for no good reason, eg

std::map<std::string, boost::any> table; ... table[key] = 0; // reasonable usage

This use case does not need an implicit constructor, just a templated operator=.

It was the spirit and sense of the expression rather than specifically the mechanism that I was referring to -- boost::any currently achieves this through a templated assignment operator. There was an implied (in)consistency that I should perhaps have stressed more clearly. Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

Kevlin Henney <kevlin@curbralan.com> writes:

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.

The conversion to boost::any isn't a widening conversion in the usual sense, though, is it? Normally, a widening conversion preserves not only the information but the *interface* of the original data -- you wouldn't consider an implicit conversion from int to string a widening conversion, would you? Similar to boost::any, you *can* go through a set of gyrations to extract the integer -- I bet that if boost::any could preserve the interface of the boxed type, Vladimir's bug wouldn't have come up. -- Dave Abrahams Boost Consulting www.boost-consulting.com