id summary reporter owner description type status milestone component version severity resolution keywords cc 2548 Let's fix the logical constness of value_initialized! niels_dekker niels_dekker "The data() member function and the conversion operator of boost::value_initialized break the logical constness: both functions are declared ""const"", while they return a non-const reference to the T object that is owned by value_initialized. I think both of them should be replaced by a pair of overloaded functions for const and non-const access. I don't think that there ever was a good reason for the data() function to break the logical constness. But clearly, there ''was'' a reason for the conversion operator to do so, at the time value_initialized was first released, in 2002. At that time, some commonly used compilers would complain about ambiguity when the conversion operator would be overloaded for const and non-const, in some specific use cases. As described at http://www.boost.org/doc/libs/1_37_0/libs/utility/value_init.htm#val_init In January 2004, ""deep const semantics"" still wasn't feasible, apparently due to compiler errors in VC++ and Borland: ''[boost] value_initialized, deep const, and template instantiation'' http://lists.boost.org/Archives/boost/2004/01/59987.php http://lists.boost.org/Archives/boost/2004/01/60020.php Nowadays I think that things have changed for the better. I just replaced the single conversion operator by overloads for const and non-const in my local copy, and tested for VC++ 2003 (7.1), VC++ 2008 (9.0), and !CodeGear 2009 (6.10). And all of them passed the tests! Therefore I'd like to propose fixing the issue, according to the attached patch. Fernando, shall we give it a try? I'm aware that the proposed fix potentially breaks some user code, but I think that those cases are easily fixed, and I think that most Boost users are likely to appreciate logical constness." Bugs closed Boost 1.38.0 utility Boost 1.37.0 Problem fixed niels_address_until_2010-10-10@…