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

On Mon, Apr 22, 2013 at 11:45 AM, Fernando Cacciola < fernando.cacciola@gmail.com> wrote:

On 22-Apr-13 12:09 PM, Mathias Gaunard wrote:

...

On 22/04/2013 15:05, Fernando Cacciola wrote:

...

On 22-Apr-13 9:37 AM, Nathan Crookston wrote:

...

Fernando Cacciola wrote:

Hi People,

...

I'm pleased to announce that thanks to the outstanding effort of Andrzej Krzemienski who wrote the standard papers, and Ville Voutilainen who champion it during the meetings, we now have std::optional<T> in C++14!

Great news! I'm almost scared to ask, but what did the committee decide concerning optional?

LOL, I knew people would ask. Well, they decided to drop it from C++14.

That's not what I remember.

I thought that what was said is that optional didn't need to be specialized,

That's technically correct.

So I should have said that our proposed specialization for T& was dropped.

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. 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.) 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). This is basically an unresolved issue that we need to solve before C++14. 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, 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). But the good news is that it is "in", and it is only the fine details that will be tweaked. I suspect more discussion on the std-proposals list. (For better or worse :-) Tony Van Eerd