[boost] Re: value_initialized, deep const, and template instantiation

From: Jim Apple (japple_at_[hidden])
Date: 2004-01-28 11:39:25

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?