Re: [boost] Transfer of Maintenance Rights (utility/value_init)

Subject: Re: [boost] Transfer of Maintenance Rights (utility/value_init)
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-03-29 21:16:34

On 3/29/2010 4:14 PM, Niels Dekker - address until 2010-10-10 wrote:
> Edward Diener wrote about https://svn.boost.org/trac/boost/ticket/3472
>> My suggested fix is so simple that it is hard for me to understand why
>> it should take so long for a decision to be made on it unless he was
>> no longer involved.
>
> Fernando Cacciola wrote:
>> Actually, your fix is NOT so simple, not conceptually.
>
> Edward replied:
>> I understand that, but I did mean syntax-wise.
>>
>> But clearly, as my argument shows, value_init can not be used in any
>> situation in which an object including a value_init value is declared as
>> a const object unless you allow the value initialized value to be
>> initialized to something other than its value-initialized default upon
>> construction ( which is my fix ). And since a developer can hardly
>> control how an end-user uses his object, whether as const or non-const,
>> essentially you are telling any developer that value_init is useless to
>> him unless he enforces the fact that his own object which has a
>> value_init value is never const, which in my opinion makes its practical
>> usage much, much less than it conceptually could be.
>>
>> How many developers do you think want to restrict their own objects to
>> non-const ? But currently value_init is practically useless to them
>> unless they do. Which is fine if you want it that way, but clearly
>> developers wanting a value_init value for a potentially const object
>> will not use it and just revert back to a default constructed object
>> which may be constructed based on an alternative constructor. Which is a
>> shame because value initialization as you have conceived and coded it is
>> much clearer and safer to use.
>
> Edward, you know I agree that it would be useful to have an extra
> value_inititialized<T> constructor to allow direct-initialization of the
> wrapped T object. It's just that I'm not entirely sure if it's a good
> idea to declare it as value_initialized(T const&).
>
> I think it would be a bit safer to add an extra "tag" parameter, to
> clarify that the constructed object is direct-initialized, instead of
> value-initialized:
>
> struct direct_initialized_t { };
>
> value_initialized(T const&, direct_initialized_t).
>
> I know you prefer your own proposed constructor, value_initialized(T
> const &), but does that mean that you're /opposed/ to having
> value_initialized(T const&, direct_initialized_t) instead?

I do not understand what the extra parameter specifying direct 
initialization is supposed to do. Making something safer implies that 
something else is not safe but I can not understand what is not safe 
with merely 'value_initialized(T const &)'. Because Microsoft, as we 
both know, has a bug with erroneous calling base class constructors of 
the type I suggested is not a reason to change code to make it 'safer'. 
One might as well change all code one writes with more elaborate 
constructs guaranteeing better 'safeness' from potential compiler bugs. 
But I do not believe this can ever be a way of doing programming.

However if your alternative is the chosen final result, it is better IMO 
than no way to initialize a value_initialized with a const T value. And 
if Fernando rejects any way to initialize a value_initialized with its T 
value I will fully understand also and, as I said, just go back to using 
default initialization for my needs.