I was a little unclear last time: by deep const I mean something<const T> is the correct indication of const, whereas by shallow const I mean const comething<T> is the correct indication of const. Fernando Cacciola wrote:
It would be very confusing if constantness semantics were to change depending on the compiler.
That's true. Broken const semantics are a problem though, especially the conversion operator. What if the working compilers had the member functions (data and operator T &, perhaps operator->) and non working compilers only had get?
For those compilers, I think there would be value to adding operator-> for the invocation of member functions, like boost::optional.
I'm not sure. operator-> generated a long discussion because of its implied pointer semantics. In the case of boost::optional<>, the possibility of the uninitialized state is my corner argument in favot of it. Yet with value_initialized<> I can't see any favorable argument.
I suppose it depends on your POV. I find get(x).f() and x.data().f() much less clear than x->f(). The reason I find the latter more clear is that it is clear that f is a member function in x's type. get(x) required me to find the get by human-driven ADL, and x.data() looks like I'm acting on a part of x.
As an alternative, deep-copy would break const expectations in generic functions that take a const T &, but it would preserve it elsewhere, so it may be worth some more thought.
Yes, though value_initalized is a value wrapper, so it must have deep-copy.
should have been "deep const". To rehash, that means deep const semantics do the wrong thing in template<typename T> void g(const T & a) {/*whatever*/} but can have the member functions, including conversion, without any worries about older compilers screaming ambiguity.
If you can guarantee proper initialization for any compiler were it is available, I'd say yes, I'm interested.
I will need someone else to do some testing for me. I'll post a candidate soon.
Should it have shallow or deep const semantics?
Deep const, as it is a value wrapper (and not a pointer wrapper)
Huh?