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

Subject: Re: [boost] Transfer of Maintenance Rights (utility/value_init)
From: Niels Dekker - address until 2010-10-10 (niels_address_until_2010-10-10_at_[hidden])
Date: 2010-03-29 16:14:58

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?

Kind regards,

   Niels
-- 
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center