Re: [boost] std::optional<T>

Subject: Re: [boost] std::optional<T>
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2013-04-22 13:15:27

On 22-Apr-13 1:31 PM, Gottlob Frege wrote:
>>   the specification without it was good enough to allow it.
>>>
>>>   Right, I thought about this and maybe it indeed just works. But I can't
>> tell for sure since I haven't sit down to test it yet.
>>
>> Best
>>
>>
>>
>
> The example implementation, as it stands, uses a union to store the T.
>   This doesn't work well with references.

Right.
That is just for non-reference types.

>  Actually, as is, I don't think
> you can put any struct that holds a reference into optional<>. ie
>
> struct Foo
> {
>     int & x;
> };
>
> union Bar
> {
>     int a, b, c;
>     Foo foo;
> };
>
> Bar fails to compile unless you give it a constructor that initializes the
> inner reference bar.foo.x.
> In the same way, optional<> when implemented with a union, would fail:
>
> optional<Foo> ofoo;
>
> Probably fails to compile.  (I don't have a complete C++11 (or C++14 :-)
> compiler, so someone correct me if I'm wrong.)
>
Interesting. I haven't thought of this (mainly because Boost.Optional 
uses aligned storage so that's no a problem).

I would imagine though that the union should allow an inner reference to 
be left unbounded.

> The union implementation is necessary for the constexpr guarantees.
>   Otherwise you could use aligned_storage.  But aligned_storage requires
> reinterpret_cast, which can't be used in constexpr context (at least not
> yet).
>
Right.

> This is basically an unresolved issue that we need to solve before C++14.

Indeed. This "problem" with reinterpret_cast and constexpr showed up in 
a couple of places and, FWIW, Andrzej and I concluded that we can't fix 
it from our side without substantially compromising std::optional<>

>   I jokingly asked for a non-normative note such as "[Note: may not be
> implementable - endnote]".
>
:)

> But we accepted optional<> anyhow, with the understanding that we will
> solve these issues somehow.  ie allow reinterpret_cast in constexpr

which is how I would like to see it fixed, since there are other places 
where that gets in the way (such as addressof() for instance)

, or
> change the constexpr guarantees of optional, etc (ie somehow use
> aligned_storage when constexpr is not needed, but use union when it is,
> etc).
>
>
> There are a few tweaks we will probably need to make for optional before
> finalization, but that can be done between now and then (particularly next
> meeting in Chicago).

I'll get to the job of updating Boost.Optional accordingly somewhere 
around next week. That will give me some experience implementing this 
new beast (Andrzej already experimented to great extent but when he 
stumble upon constexpr issues, he decided to just drop it for the moment)

> But the good news is that it is "in", and it is only the fine details that
> will be tweaked.
>
Absolutely.

> I suspect more discussion on the std-proposals list. (For better or worse
> :-)
>
See you there :)

Best