Re: [boost] [optional] std::tr2::optional

Subject: Re: [boost] [optional] std::tr2::optional
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-11-18 12:26:31

Le 18/11/11 16:24, Andrzej Krzemienski a écrit :
> Hi,
> I use boost::optional quite often, find it very useful, and cannot imagine
> that it could not get into TR2. I am considering writing a proposal for
> adding it myself (if it is possible to propose things without attending the
> committee meetings), but I would first want to know how boost::optional
> could be improved given the new features in C++11. I provide a list of
> modifications that I could think of. What is your opinion?
Hi,

good idea.
>
> * Conversion explicit conversion to bool should be declared as explicit.
Doesn't an explicit conversion disallows to use it in a conditional 
expression as in

if(opt) {}
> * Should exception safety guarantees for assignment operations be enforced?
> In boost::optional they only provide a basic guarantee.
> One option is to provide strong guarantee for types T which implement
> operator= with strong guarantee, and give basic guarantee for other cases
> Other option (not sure if it is possible) is to provide strong guarantee
> for all cases at the cost of run-time performance (heap allocation).
Provide the same exception guaranties as the T assignment seems the more 
reasonable.
> * Add move operations
> optional<T>  &  operator=( optional<T>  &&  ) noexcept(
> nothrow_move_constructible<T>::value );
> optional<T>  &  operator=( T&&  ) noexcept(
> nothrow_move_constructible<T>::value );
+1
> * move operations for optional references?
> But I am not sure what optional references are for...
>
> * What are optional references for anyway?
>
> * it could add an rvalue reference overload for stored object access:
> T&&  operator*( )&&
> However using this overload implies that the user is not checking if an
> optional has been initialized, so it may encourage a bad practice.
>
> * Are in-place factories necessary if we have perfect forwarding? Instead,
> we can provide a reset function and a "variadic constructor":
>
> template<  typename ... Args>
> void reset( Args&&  ...args );
>
> template<  typename ... Args>
> optional( Args&&  ...args );
I like them.
> The constructor will clash with another optional constructor:
> optional<T>::optional( bool cond, const T&  val );

I don't understand why.
> but perhaps it is not needed if we have
> std::optional<T>  std::make_optional( bool cond,const T&  val );
> and move construction of optionals?

* noexcept default construction and destroy operations

+1
> * constexpr default ctor
+1
> * Use nullptr instead of boost::none? - this will make some uses of
> optional pointers harder, but will make usage more clear in other cases.
>
>
I have nothing against none. Optional is not a pointer and initializing 
it with nullptr could induce the user to think that it could be one pointer.

Best,
Vicente