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