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 14:56:19

On 3/29/2010 10:54 AM, Fernando Cacciola wrote:
> Hi Edward,
>
>> On 3/27/2010 7:20 PM, Niels Dekker - address until 2010-10-10 wrote:
>>> Edward Diener wrote:
>>>> I will cite a few where it seems to me that the original developer
>>>> is nowhere around anymore, but this is just subjective and I might
>>>> be totally wrong:
>>> ...
>>>> value_init
>>>
>>> As far as I know, Fernando Cacciola, the original developer of
>>> utility/value_init, is still around. I've been doing some maintenance to
>>> value_init as well, reviewed by Fernando. And I'm still busy fixing
>>> "Unconditional call to memset in value_initialized()"
>>> <https://svn.boost.org/trac/boost/ticket/3869>. Unfortunately I haven't
>>> got enough time to finalize the fix this month, sorry! I hope to do so
>>> before the end of April.
>>
>> I am aware that you have taken over some of the work on it from Fernando.
>>
>>>
>>> We still need to have a decision about your "Setting
>>> value_initialized<T> to a value when T is a top-level const"
>>> <https://svn.boost.org/trac/boost/ticket/3472>. You know, I wasn't
>>> entirely sure about your proposed fix, so I proposed a slightly
>>> different fix. I still hope Fernando can make a choice between the two.
>>
>> I never heard back from Fernando about this so I assumed he was no
>> longer active as a maintainer of his library.
>
> I guess you can say that, though is not I'm intentionally out of the
> loop. I just never have the time.
>
>> 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.
>
> Actually, your fix is NOT so simple, not conceptually.

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.

> That's why Niels
> proposed something else.
> Anyway a decision needs to be made and if I won't do it on time (for
> whatever reason), someone else must be given the mantaince rights.
> Having said that, I'll make a decision in the next few days.

It is appreciated.