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. We decided to submit a couple of variations to the proposal, in order to avoid getting it rejected because of one or another controversial point. The variation that got accepted is the one without optional references. Best

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

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

On 22-Apr-13 1:52 PM, Andrey Semashev wrote:

On Monday 22 April 2013 12:45:58 Fernando Cacciola 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.

First, congratulations! I'm happy to see this component is making its way into the standard.

:)

Second, if I understand correctly, without specializing optional for references, optional will be suboptimal (i.e. it will essentially be a pointer and a bool instead of just a pointer). Why not requiring this optimization?

AFAICT, you cannot require any optimization for a library component in the STD. At most you can add a note suggesting this or that implementation. In any case, have in mind that an implementation would be free to store just a pointer in the case of provided it conforms to the specification. The "proposal for references" that I mentioned is not intended to accommodate implementations but to explicitly specify special semantics that I think are important and which do not directly derive from the general case. Best

On 22-Apr-13 10:07 AM, Antony Polukhin wrote:

2013/4/22 Fernando Cacciola :

...

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!

Cheers

Congratulations! Happy to hear it!

BTW, what will happen with Boost.Optional in nearest future: rvalues and constexpr fetures support will be added? Will it (and C++14 version) be optimized for bool, short and other small types?

Yes. I postponed all changes to Boost.Optional until the standardization finished in order to make it as close as possible to the std version (there are a number of relevant API elements that are better in sync) Now that I know what's been accepted, I can and will work on it. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

2013/4/22 niXman

2013/4/22 Fernando Cacciola:

...

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!

Good news! Congratulations!

Tell me please, where I can find the list of what is accepted in C++14, not that only suggested ? Thanks.

For high level overview, see this report from Herb Sutter: http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting. Regards, &rzej