220 2850 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: std::optional -- request for feedback on the wording Date: Fri, 15 Feb 2013 05:44:08 -0800 (PST) Lines: 5671 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1783_16865104.1360935848759" X-Trace: ger.gmane.org 1360935987 25895 80.91.229.3 (15 Feb 2013 13:46:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Feb 2013 13:46:27 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDT2DGOJ34DBBGPY7CEAKGQEILGC3AQ@isocpp.org Fri Feb 15 14:46:32 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gg0-f197.google.com ([209.85.161.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U6LcN-00026v-6T for gclcip-std-proposals@m.gmane.org; Fri, 15 Feb 2013 14:46:24 +0100 Original-Received: by mail-gg0-f197.google.com with SMTP id k5sf822326ggn.4 for ; Fri, 15 Feb 2013 05:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=d1ePBycoMbjR+0hX5SWYDI+VFBNzwEGAHX9lzsK4SIY=; b=w9EIFeFZCR0s0VmyGbg/O01Rx0vTZFSlzj3UD6moSiilLi+aKqh2tbeHKyyj47kRPg UJZoZtEVDre8vR55E4Qg9vWYro6SyGU/qz8gPpEfQ4qTIFJp1+uDHX3O1uwfIkQwb0eh S6/AceQK4geSqGA85smz+7II/BH7Teow1NZEU2XL5ZgkfrIvb1jFFxUcrJBFlZ/6DAgX aUJwZGIyOHfh9tkSODHCxpeycveS2QtsABzKdXM69Sd0iJu6mYnFTMU7v3j2/aGbZo+A 1DJVAs1gSfLwxQEMfFcDT4GwuFy5hDFxfNZOxfL+3GDALT61FuhfoNO8U6j0H6WmL15M 9Fwg== X-Received: by 10.236.82.102 with SMTP id n66mr1145262yhe.28.1360935962461; Fri, 15 Feb 2013 05:46:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.39.231 with SMTP id s7ls856665qek.47.gmail; Fri, 15 Feb 2013 05:46:01 -0800 (PST) X-Received: by 10.49.34.135 with SMTP id z7mr68189qei.1.1360935961532; Fri, 15 Feb 2013 05:46:01 -0800 (PST) X-Original-Sender: akrzemi1@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:2850 Archived-At: ------=_Part_1783_16865104.1360935848759 Content-Type: multipart/alternative; boundary="----=_Part_1784_17530136.1360935848759" ------=_Part_1784_17530136.1360935848759 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone, We have updated the proposal based on recent feedback. I enclose the latest= =20 draft. It is also available at: http://kojot.sggw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html Changes include: 1. Semantics of mixed relops for irregular types (thanks to Tony Van=20 Eerd) 2. Removed postconditions that would not be possible to achieve for=20 irregular types (thanks to Tony Van Eerd) 3. operator-> and most of operations on optional refs are not constexpr= =20 if our type has overloaded operator& (because there is no way to impleme= nt=20 a constexpr addressof) (thanks to Nicol Bolas) 4. Added function value() that throws on disengaged optionals (thanks to= =20 Daniel Kr=FCgler) =20 We would appreciate your feedback, especially on the standardese. Regards, &rzej --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/?hl=3Den. ------=_Part_1784_17530136.1360935848759 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone,
We have updated the proposal based on recent feedback. I en= close the latest draft. It is also available at:
http://kojot.sg= gw.waw.pl/~akrzemi1/optional/tr2.optional.proposal.html
Changes incl= ude:
  1. Semantics of mixed relops for irregular types (thanks to To= ny Van Eerd)
  2. Removed postconditions that would not be possible = to achieve for irregular types (thanks to Tony Van Eerd)
  3. operator-&= gt; and most of operations on optional refs are not constexpr if our type h= as overloaded operator& (because there is no way to implement a constex= pr addressof) (thanks to Nicol Bolas)
  4. Added function value() that t= hrows on disengaged optionals (thanks to Daniel Kr=FCgler)

= We would appreciate your feedback, especially on the standardese.

Reg= ards,
&rzej

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-pro= posals/?hl=3Den.
 
 
------=_Part_1784_17530136.1360935848759-- ------=_Part_1783_16865104.1360935848759 Content-Type: text/html; charset=US-ASCII; name=tr2.optional.proposal.html Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=tr2.optional.proposal.html X-Attachment-Id: 9d4f679e-8e2e-4947-8e45-7053fee56477 Content-ID: <9d4f679e-8e2e-4947-8e45-7053fee56477> A proposal to add a utility class to represent optional objects (Rev= ision 2)

A proposal to add a utility class to represent option= al objects (Revision 3)

ISO/IEC JTC1 SC22 WG21 D3527

Fernando Cacciola, fernando.cacciola@gmail.com
Andrzej Krzemieński, akrzemi1@gmail.com

Introduction

Class template optional<T> proposed here is a type th= at may or may not store a value of type T in its storage space= .. Its interface allows to query if a value of type T is curren= tly stored, and if so, to access it. The interface is based on Fernando Cac= ciola's Boost.Optional library[2], shipping since March, 2003, a= nd widely used. It requires no changes to core language, and breaks no exis= ting code.

Table of contents

Revision history

Changes since N3406=3D12-0096:

  • optional<T> is hashable for hashable T’s.
  • Optional refereces are now an auxiliary proposal — this gives t= he possibility to accept optional values without references.
  • Optional refereces are now assignamble and swappable.
  • get_value_or is now optional-specific membe= r function, renamed to value_or.
  • Added member function value — an alternative to operator* that checks if the object is engaged.
  • optional<T> is a literal type.
  • Mixed relational operations between optional<T> an= d T are now allowed.
  • Removed reference implementation. We now only provide the implementat= ion of the parts that we consider non-trivial.

Changes since N1878=3D05-0138:

  • Revised wording; the changes are now relative to N3290.
  • Removed any form of assignment for optional references.
  • Removed duplicate interface for accessing the value stored by the opt= ional.
  • Added in-place construction and assignment.
  • Now using different tag nullopt instead of nullptr= to indicate the 'disengaged' (uninitialized) optional.
  • Included C++11 features: move semantics, noexcept, varia= dic templates, perfect forwarding, static initialization.
  • Changed the motivation section.
  • Changed the design rationale section.
  • Added reference implementation

Motivation and scope

Missing return values

It sometimes happens that a function that is declared to return values o= f type T may not have a value to return. For one instance, con= sider function double sqrt(double). It is not defined for nega= tive numbers. The only way function sqrt can find itself in= the situation where it cannot produce a value is when it is passed an inva= lid argument, and it is possible for the caller to check if the argument is= valid. Therefore, such cases are dealt with by stating a function prec= ondition. Violating the precondition may either result in undefined be= havior, or (as it is the case for std::vector::at) may be defi= ned to throw an exception. However, there are cases where we cannot know wh= ether a function is able to return a value before we call it. For instance:= =20 

char c =3D stream.getNextChar();
int x =3D DB.execute("select x_coord from coordinates where point_id =3D 11=
2209");

In the first case, one could argue that stream could provid= e another function for checking if the end of stream has been reached. But = for the latter there is no easy way to make sure that the requested informa= tion exists in the database before we request for it. Also, throwing an exc= eption is not a good solution, because there is nothing unusual or erroneou= s about not having found a record in the DB.

Optional function arguments

Sometimes it is useful to indicate that we are unable to, or do not want= to, provide one of the function arguments:

void execute( function<void(int)> fa, function<void(int)> =
fb )
{
  int i =3D computeI();
  fa(i); // implicit assumption that fa !=3D nullptr
  if (fb) {
    fb(i);
  }
}

Here, fb is an optional argument: it may simply repre= sent no function. It typically requires an if-statement in function body. I= t is often argued that such design can be replaced by providing two functio= n overloads; however, this also is problematic: it adds certain duplication= ; may make the code less clear; the number of overloads increases expotenti= ally with the number of optional parameters. std::function is = already an optional type, however, other types in general are not; for inst= ance, std::pair<int, std::string>.

Indicating a null-state

Some types are capable of storing a special null-state or n= ull-value. It indicates that no 'meaningful' value has been assigned t= o the object yet. It is then possible to query the object whether it contai= ns a null-state, typically by invoking a contextual conversion to type bool or by checking for equality with nullptr. Exampl= es of such types include: std::unique_ptr or std::functi= on. This is convenient for instance when implementing a lazy init= ialization optimization: 

class Car=20
{
  mutable mutex m_;
  mutable unique_ptr<const Engine> engine_;
 =20
public:
  const Engine& engine() const
  {
    lock_guard<mutex> _(m_);
    if (engine_ =3D=3D nullptr) {
      engine_.reset( new engine{engineParams()} );
    }
    return *engine_;
  }
};

Other types, on the other hand, do not provide this capability. For inst= ance, type int does not have a special value that would signal= the null-state. Any value of int is a valid value. The same g= oes for user defined types: e.g., Rational<int> that imp= lements a rational number by holding two int’s represent= ing a numerator and a denumerator.

For a similar example, consider this function for finding biggest = int.

int find_biggest( const vector<int>& vec )
{
  int biggest; // =3D what initial value??
  for (int val : vec) {
    if (biggest < val) {
      biggest =3D val;
    }
  }
  return biggest;
}=20

What initial value should we assign to biggest? Not 0, because= the vector may hold negative values. We can use std::numeric_limits&= lt;int>::min(). But what if we want to make our function generic?= std::numeric_limits will not be specialized for any possible = type. And what if the vector contains no elements? Shall we return minimum = possible value? But how will the caller know if the size of the vector was = zero, or if it was one with the minimum possible value?

Manually controlling the lifetime of scop= e guards

Consider that you have to run three actions in the fixed order: 

void runAction1( Resource1 & );
void runAction2( Resource1 &, Resource2 & );
void runAction3( Resource2 & );

Of course, the two resources need to be acquired before using them and r= eleased once we are done. This is how we would write it conceptually, if we= could assume that none of the operations ever fails or throws exceptions:<= /p> 

Result run3Actions( Parameter param ) // BAD!!
{
  Resource1 res1;
  Resource2 res2;

  res1.acquire(param);       // res1 scope
  runAction1( res1 );        //
  res2.acquire(param);       //    // res2 scope
  runAction2( res1, res2 );  //    //
  res1.release();            //    //
  runAction3( res2 );              //
  res2.release();                  //
}

Note that the scopes of the two resources overlap. we cannot cl= early divide our function into nested scopes that correspond to lifetimes o= f the resources. This example represents a real-life situation if you imagi= ne that runAction2 is a critical operation, and runAction3 (and perhaps runAction1) is logging, which we can even skip if = it fails.

Of course, this code is unacceptable, because it does not take into acco= unt that acquire operations, and the three actions may fail. So, we want t= o rewrite run3Actions using RAII idiom. Especially, that the libra= ry author that provides the interface to the two resources also knows that = RAII is probably always what we want and the only interface he provides are= scope guards:=20 

Result run3Actions( Parameter param ) // selfish
{
  Resource1Guard res1{param};
  Resource2Guard res2{param};

  runAction1( res1 );
  runAction2( res1, res2 );  =20
  runAction3( res2 );
}

This solution is somewhat elegant: you first acquire all resources that = you will need, and once you are sure you have them all, you just run the ac= tions. But it has one problem. Someone else will also need to use resources= we are acquiring. If they need it at the moment, but we own the resource r= ight now, they will be locked, or thrown a refusal exception — they w= ill be disturbed and delayed. Using a resource is a critical part of the pr= ogram, and we should be only acquiring them for as short a period as possib= le, for the sake of efficiency: not only our program's but of the entire op= erating system. In our example above, we hold the ownership of res2 while executing runAction1, which does not require the resource.= Similarly, we unnecessarily hold res1 when calling runAction3= .

So, how about this?

Result run3Actions( Parameter param ) // slow and risky
{
  {
    Resource1Guard res1{param};
    runAction1( res1 );
  }
  {
    Resource1Guard res1{param};
    Resource2Guard res2{param};
    runAction2( res1, res2 ); =20
  } =20
  {
    Resource2Guard res2{param};
    runAction3( res2 );
  }=20
}

It does not have the above-mentioned problem, but it introduces a differ= ent one. Now we have to acquire the same resource two times in a row for tw= o subsequent actions. Resource acquisition is critical, may lock us, may sl= ow us down, may fail; calling it four times rather than two is wrong, espec= ially that acquiring the same resource twice may give us different resource= properties in each acquisition, and it may not work for our actions.

= =20

Skipping the expensive initialization

Not all types provide a cheap default construction, even if they are sma= ll in size. If we want to put such types in certain containers, we are risk= ing paying the price of expensive default construction even if we want to a= ssign a different value a second later. 

ExpensiveCtor array[100]; // 100 default constructions
std::array<ExpensiveCtor, 100> arr; // 100 default constructions<=
/em>
std::vector<ExpensiveCtor> vec(100); // 100 default constructions=

Current techniques for solving the prob= lems

The above mentioned problems are usually dealt with in C++ in three ways= :

  1. Using ad-hoc special values, like EOF, -1, 0, nume= ric_limits<T>::min().
  2. Using additional flags, like pair<T, bool>.
  3. Using pointers even if the object would have been passed or returned = by value if it wouldn't be possibly absent.

Technique (1) suffers from the lack of uniformity. Special value, like <= code>EOF is not something characteristic of the type (int), but of the particular function. Other function may need to use a diffe= rent special value. The notable example is the standard function atoi= , where 0 may indicate either an unsuccessful conversion, or a succe= ssful conversion to value 0. And again, sometimes it is not even possible t= o designate a value with a special meaning, because all values of a given t= ype are equally likely to appear; for instance: 

bool accepted =3D DB.execute("select accepted from invitations where i=
nvitation_id =3D 132208");

Technique (2) is problematic because it requires both members of p= air to be initialized. But one of the reasons we are not returning a= 'normal' value from a function or do not want to initialize the object jus= t yet, is because we did not know how to initialize it. In case of optional= int we could give it a rubbish value or leave it uninitialize= d, but user defined types, including resources, may not provide a default c= onstructor, and require some effort to perform initialization.

Technique (3) is general. It uses value nullptr to indicate= the special value. Users can unequivocally test if the value is indeed abs= ent and being formally undefined behavior to access an object pointed to by= a null pointer. It also does not require initializing the object unnecessa= rily. But it comes with different problems. Automatic objects created insid= e functions cannot be returned by pointer. Thus it often requires creating = objects in free store which may be more expensive than the expensive initia= lization itself. It also requires manual memory management problems. The la= tter problem can be dealt with by using std::unique_ptr, but t= his is still a pointer, and we must abandon value semantics. Now we return = a smart pointer: we have shallow copy and shallow comparison.

Impact on the Standard

This proposal depends on library proposal N3471: it requires tha= t Standard Library components move, forward and m= ember functions of initializer_list are constexpr= .. The paper has already been incorporated into the Working Draft of the Sta= ndard N3485. This proposal also depends on language proposal N2439 (= Rvalue references for *this). While the latter feature proposa= l has been incorporated into C++11, we are not aware of any compiler implem= entation. There is a risk that if compiler vendors do not implement it, the= y will also not be able to fully implement this proposal. In that case, the= signature of member function optional<T>::value_or from= this proposal will need to be modified.

N3507 (A URI Library for C++) depends on this library.

Overview of optional

The primary purpose of optional<T>'s interface is to = be able to answer the quesiotn "do you contain a value of type T?", and iff the answer is "yes", to provide access to the contained value= .. Conceptually, optional can be illustrated by the following s= tructure.

template <typename T>
struct optional
{
  bool is_initialized_;
  typename aligned_storage<sizeof(T), alignof(T)>::type storage_;
};

Flag is_initialized_ stores the information if option= al has been assigned a value of type T. storage_<= /code> is a raw fragment of memory (allocated within optional = object) capable of storing an object of type T. Objects in thi= s storage are created and destroyed using placement new and ps= eudo destructor call as member functions of optional are execu= ted and based on the value of flag is_initialized_.

=20

Alternatively, one can think of optional<T> as = pair<bool, T>, with one important difference: if first is false, member second has never been even= initialized, even with default constructor or value-initialization.

The basic usage of optional<T> can be illustrated wit= h the following example.

optional<int> str2int(string);    // converts int to string =
if possible

int get_int_form_user()
{
  string s;

  for (;;) {
    cin >> s;
    optional<int> o =3D str2int(s); // 'o' may or may not contain=
 an int
    if (o) {                      // does optional contain a value?
      return *o;                  // use the value
    }
  }
}

Interface of optional

Default construction of optional<T> creates an an obj= ect that stores no value of type T. No default constructor of = T is called. T doesn't even need to be Defa= ultConstructible. We say that thus created optional object is di= sengaged. We use a pair of somewhat arbitrary names, 'engaged' and 'di= sengaged'. A default-constructed optional object is initialized (the lifeti= me of optional<T> has started), but it is disengaged (th= e lifetime of the contained object has not yet started). Trying to access t= he value of T in this state causes undefined behavior. The onl= y thing we can do with a disengaged optional object is to query whether it = is engaged, copy it, compare it with another optional<T>= , or engage it.

optional<int> oi;                 // create disengaged objec=
t
optional<int> oj =3D nullopt;       // alternative syntax
oi =3D oj;                          // assign disengaged object
optional<int> ok =3D oj;            // ok is disengaged

if (oi)  assert(false);           // 'if oi is engaged...'
if (!oi) assert(true);            // 'if oi is disengaged...'

if (oi !=3D nullopt) assert(false); // 'if oi is engaged...'
if (oi =3D=3D nullopt) assert(true);  // 'if oi is disengaged...'

assert(oi =3D=3D ok);                 // two disengaged optionals compa=
re equal

Tag nullopt represents the disengaged state of an optional = object. This reflects our conceptual model of optional objects: optio= nal<T> can be thought of as a T with one addition= al value nullopt. Being disengaged is just another value of T. Thus, optional<unsigned> can be thought of= as a type with possible range of values {nullopt, 0, 1, ...}.= Value nullopt is always picked by the default constructor.

We can create engaged optional objects or engage existing optional objec= ts by using converting constructor (from type T) or by assigni= ng a value of type T. 

optional<int> ol{1};              // ol is engaged; its cont=
ained value is 1
ok =3D 2;                           // ok becomes engaged; its containe=
d value is 2
oj =3D ol;                          // oj becomes engaged; its containe=
d value is 1

assert(oi !=3D ol);                 // disengaged !=3D engaged
assert(ok !=3D ol);                 // different contained values
assert(oj =3D=3D ol);                 // same contained value
assert(oi < ol);                  // disengaged < engaged
assert(ol < ok);                  // less by contained value

Copy constructor and copy assignment of optional<T> c= opies both the engaged/disangaged flag and the contained value, if it exist= s. 

optional<int> om{1};              // om is engaged; its cont=
ained value is 1
optional<int> on =3D om;            // on is engaged; its contain=
ed value is 1
om =3D 2;                           // om is engaged; its contained val=
ue is 2
assert (on !=3D om);                // on still contains 3. They are no=
t pointers

We access the contained value using the indirection operator.

int i =3D *ol;                      // i obtains the value contain=
ed in ol
assert(i =3D=3D 1);
*ol =3D 9;                          // the object contained in ol becom=
es 9
assert(*ol =3D=3D 9);

We also provide consistent operator->. Even though optional provides operators -> and * i= t is not a pointer. Unlike pointers, it has full value semantics: deep copy= construction, deep copy assignmet, deep equality and less-than comparison,= and constness propagation (from optional object to the contained value). 

int p =3D 1;
optional<int> op =3D p;
assert(*op =3D=3D 1);
p =3D 2;                        =20
assert(*op =3D=3D 1);                 // value contained in op is separ=
ated from p

The typical usage of optional requires an if-statement.

if (ol)                     =20
  process(*ol);                   // use contained value if present
else
  processNil();                   // proceed without contained value
 =20
if (!om)  =20
  processNil();
else =20
  process(*om);    =20
=20

If the action to be taken for disengaged optional is to pro= ceed with the default value, we provide a convenient idiom:

=20 
process(ol.value_or(0));      // use 0 if ol is disengaged

Sometimes the initialization from T may not do. If we want = to skip the copy/move construction for T because it is too exp= ensive or simply not available, we can call an 'emplacing' constructor, or = function emplace.

optional<Guard> oga;                     // Guard is non-cop=
yable (and non-moveable)    =20
optional<Guard> ogb(emplace, "res1");    // initialzes the contai=
ned value with "res1"           =20
optional<Guard> ogc(emplace);            // default-constructs th=
e contained value

oga.emplace("res1");                     // initialzes the contained va=
lue with "res1" =20
oga.emplace();                           // destroys the contained valu=
e and 
                                         // default-constructs the new =
one

There are two ways to disengage a perhaps engaged optional obje= ct:

ok =3D nullopt;                      // if ok was engaged calls T'=
s dtor
oj =3D {};                           // assigns a temporary disengaged =
optional
oga =3D nullopt;                     // OK: disengage the optional Guar=
d
ogb =3D {};                          // ERROR: Guard is not Moveable

Optional propagates constness to its contained value:

const optional<int> c =3D 4;=20
int i =3D *c;                        // i becomes 4
*c =3D i;                            // ERROR: cannot assign to const i=
nt&

Exception safety

Type optional<T> is a wrapper over T, th= us its exception safety guarantees depend on exception safety guarantees of= T. We expect (as is the case for the entire C++ Standard Libr= ary) that destructor of T does not throw exceptions. Copy assi= gnment of optional<T> provides the same exception guaran= tee as copy assignment of T and copy constructor of T (i.e., the weakest of the two). Move assignment of optional<T= > provides the same exception guarantee as move assignment of T and move constructor of T. Member function e= mplace provides basic guarantee: if exception is thrown, optio= nal<T> becomes disengaged, regardless of its prior state.

Advanced use cases

With optional<T> problems described in Motivation sec= tion can be solved as follows. For lazy initialization:

class Car=20
{
  mutable mutex m_;
  mutable optional<const Engine> engine_;
  mutable optional<const int> mileage_
 =20
public:
  const Engine& engine() const
  {
    lock_guard<mutex> _(m_);
    if (engine_ =3D=3D nullopt) engine_.emplace( engineParams() );
    return *engine_;
  }
 =20
  const int& mileage() const
  {
    lock_guard<mutex> _(m_);
    if (!mileage_) mileage_ =3D initMileage();
    return *mileage_;
  }
};

The algorithm for finding the greatest element in vector can be written = as: 

optional<int> find_biggest( const vector<int>& vec )
{
  optional<int> biggest;  // initialized to not-an-int
  for (int val : vec) {
    if (!biggest || *biggest < val) {
      biggest =3D val;
      // or: biggest.emplace(val);
    }
  }
  return biggest;
}=20

Missing return values are naturally modelled by optional values:

optional<char> c =3D stream.getNextChar();
optional<int> x =3D DB.execute("select ...");

storeChar( c.value_or('\0') );
storeCount( x.value_or(-1) );

Optional arguments can be implemented as follows:

template <typename T>
T getValue( optional<T> newVal =3D nullopt )
{
  if (newVal) {
    cached =3D *newVal;    =20
  }
  return cached;     =20
}

Manually controlling the life-time of guard-like objects can be achieved= by emplacement operations and nullopt assignment:

{
  optional<Guard> grd1{emplace, "res1", 1};   // guard 1 initiali=
zed
  optional<Guard> grd2;

  grd2.emplace("res2", 2);                     // guard 2 initialized
  grd1 =3D nullopt;                              // guard 1 released

}                                              // guard 2 released (in =
dtor)

It is possible to use tuple and optional to em= ulate multiple return valuse for types without default constructor:

tuple<Date, Date, Date> getStartMidEnd();
void run(Date const&, Date const&, Date const&);
// ...

optional<Date> start, mid, end;           // Date doesn't have de=
fault ctor (no good default date)

tie(start, mid, end) =3D getStartMidEnd();
run(*start, *mid, *end);=20

Comparison with value_p= tr

N3339[7] proposes a smart pointer template value= _ptr. In short, it is a smart pointer with deep copy semantics. It h= as a couple of features in common with optional: both contain = the notion of optionality, both are deep-copyable. Below we list the most i= mportant differences.

value_ptr requires that the pointed-to object is allocated = in the free store. This means that the sizeof(value_ptr<T>) is fixed irrespective of T. value_ptr is 'pol= ymorphic': object of type value_ptr<T> can point to an o= bject of type DT, derived from T. The deep copy p= reserves the dynamic type. optional requires no free store all= ocation: its creation is more efficient; it is not "polymorphic".

Relational operations on value_ptr are shallow: only addres= ses are compared. Relational operations on optional are deep, = based on object's value. In general, optional has a well defin= ed value: being disengaged and the value of contained value (if it exists);= this value is expressed in the semantics of equality operator. This makes = optional a full value-semantic type. Comparison of value= _ptr does not have this property: copy semantics are incompatible wi= th equality comparison semantics: a copy-constructed value_ptr= does not compare equal to the original. value_ptr is not a va= lue semantic type.=20

Design rationale

The very minimum, ascetic interface for optional objects — apart f= rom copy/move — could consist of two constructors and two functions:<= /p> 

// not proposed
int i =3D 9;
optional<int> oi{engaged, i};          // create engaged
optional<int> oj{disengaged};          // create disengaged
if (oi.is_engaged()) {                 // contains value?
  oi.get_value();                      // access the value
}

The reason we provide different and richer interface is motivated by use= rs' convenience, performance improvements, secondary goals we want to achei= ve, and the attempt to standardize the existing practice.

Nearly every function in the interface of optional has rise= n some controversies. Different people have different expectations and diff= erent concerns and it is not possible to satisfy all conflicting requiremen= ts. Yet, we believe that optional is so universally useful, th= at it is worth standardizing it even at the expense of introducing a contor= versial interface. The current proposal reflects our arbitrary choice of ba= lance between unambiguousity, genericity and flexibility of the interface. = The interface is based on Fernanndo Cacciola's Boost.Optional l= ibrary,[2] and the users' feedback. The library has been widely = accepted, used and even occasionally recommended ever since.=20

Conceptual model for optional<T>= ;

Optional objects serve a number of purposes and a couple of conceptual m= odels can be provided to answer the question what optional<T> really is and what interface it should provide. The three most common= models are:

  1. Just a T with deferred initialization (and additional in= terface to check if the object has already been initialized).
  2. A discriminated union of types nullopt_t and T.
  3. A container of T's with the maximum size of 1.

While (1) was the first motivation for optional, we do not = choose to apply this model, because type optional<T> wou= ld not be a value semantic type: it would not model concept Regular (if C++ had concepts). In particular, it would be not clear whather b= eing engaged or disengaged is part of the object's state. Programmers who w= ish to adapt this view, and don't mind the mentioned difficulties, can stil= l use optional this way:

optional<int> oi;
initializeSomehow(oi);

int i =3D (*oi);
use(*oi);
(*oi) =3D 2;
cout << (*oi);

Note that this usage does not even require to check for engaged state, i= f one is sure that the object is engaged. One just needs to use indirection= operator consistently anywhere one means to use the initialized value.

Model (2) treats optional<T> as etier a value of type= T or value nullopt, allocated in the same storag= e, along with the way of determining which of the two it is. The interface = in this model requires operations such as comparison to T, com= parison to nullopt, assignment and creation from either. It is= easy to determine what the value of the optional object is in this model: = the type it stores (T or nullopt_t) and possibly = the value of T. This is the model that we propose.

Model (3) treats optional<T> as a special case contai= ner. This begs for a container-like interface: empty to check = if the object is disengaged, emplace to engage the object, and= clear to disengage it. Also, the value of optional object in = this model is well defined: the size of the container (0 or 1) and the valu= e of the element if the size is 1. This model would serve our pupose equall= y well. The choice between models (2) and (3) is to a certain degree arbitr= ary. One argument in favour of (2) is that it has been used in practise for= a while in Boost.Optional.

Additionally, within the affordable limits, we propose the view that optional<T> just extends the set of the values of T by one additional value nullopt. This is reflected in in= itialization, assignment, ordering, and equality comparison with both T and nullopt.

optional<int> oi =3D 0;
optional<int> oj =3D 1;
optional<int> ok =3D nullopt;

oi =3D 1;
oj =3D nullopt;
ok =3D 0;

oi =3D=3D nullopt;
oj =3D=3D 0;
ok =3D=3D 1;

Initialization of o= ptional<T>

In cases T is a value semantic type capable of storing = n distinct values, optional<T> can be seen as an ex= tended T capable of storing n + 1 values: these that = T stores and nullopt. Any valid initialization sc= heme must provide a way to put an optional object to any of these states. I= n addition, some Ts (like scope guards) are not MoveCons= tructible and their optional variants still should constructible wit= h any set of arguments that work for T. Two models have been i= dentified as feasible.

The first requires that you initialize either by providing an already co= nstructed T on the tag nullopt.

string s{"STR"};

optional<string> os{s};                    // requires Copyable&l=
t;T>
optional<string> ot =3D s;                   // requires Copyable=
<T>
optional<string> ou{"STR"};                // requires Movable<=
;T>
optional<string> ov =3D string{"STR"};       // requires Movable&=
lt;T>

optional<string> ow;                       // disengaged
optional<string> ox{};                     // disengaged
optional<string> oy =3D {};                  // disengaged
optional<string> oz =3D optional<string>{};  // disengaged<=
/em>
optional<string> op{nullopt};              // disengaged
optional<string> oq =3D {nullopt};           // disengaged

In order to avoid calling move/copy constructor of T, we us= e a 'tagged' placement constructor: 

optional<Guard> og;                        // disengaged
optional<Guard> oh{};                      // disengaged
optional<Guard> oi{emplace};               // calls Guard{} in pl=
ace
optional<Guard> oj{emplace, "arg"};        // calls Guard{"arg"} =
in place

The in-place constructor is not strictly necessary. It could be dropped = because one can always achieve the same effect with a two-liner:

optional<Guard> oj;                        // start disengag=
ed
oj.emplace("arg");                         // now engage

Notably, there are two ways to create a disengaged optional object: eith= er by using the default constructor or by calling the 'tagged constructor' = that takes nullopt. One of these could be safely removed and <= code>optional<T> could still be initialized to any state.

An alternative and also comprehensive initialization scheme is to have a= variadic perfect forwarding constructor that just forwards any set of argu= ments to the constructor of the contained object of type T: 

// not proposed

optional<string> os{"STR"};                // calls string{"STR"}=
 in place 
optional<string> ot{2, 'a'};               // calls string{2, 'a'=
} in place
optional<string> ou{};                     // calls string{} in p=
lace
optional<string> or;                       // calls string{} in p=
lace

optional<Guard> og;                        // calls Guard{} in pl=
ace
optional<Guard> oh{};                      // calls Guard{} in pl=
ace
optional<Guard> ok{"arg"};                 // calls Guard{"arg"} =
in place

optional<vector<int>> ov;                  // creates 0-ele=
ment vector
optional<vector<int>> ow{};                // creates 0-ele=
ment vector
optional<vector<int>> ox{5, 6};            // creates 5-ele=
ment vector
optional<vector<int>> oy{{5, 6}};          // creates 2-ele=
ment vector

In order to create a disengaged optional object a special tag needs to b= e used: either nullopt or T-based:

optional<int> oi =3D nullopt;                // disengaged <=
/em>
optional<int> oj =3D optional<int>::nullopt; // disengaged<=
/em>

The latter, perfect forwarding variant, has an obvious advantage: whatev= er you can initialize T with, you can also use it to initializ= e optional<T> with the same semantics. It becomes even m= ore useful in copy-initialization contexts like returning values from funct= ions or passing arguments to functions:

void putch(optional<char> oc);
putch('c');
putch({});       // char '\0'
putch(nullopt);  // no char

However, there are also certain problems with this model. First, there = are exceptions to perfect forwarding: the tag nullopt is not f= orwarded. Also, arguments of type optional<T> are not. T= his becomes visible if T has such constructor:

struct MyType
{
  MyType(optional<MyType>, int =3D 0);
  // ... 
};

Also, in general, it is impossible to perfect-forward initializer_= list as the special deduction rules are involved. Second problem is = that optional's default constructor creates an engaged object = and therby triggers the value-initialization of T. It can be a= rgued that this is only a psychological argument resulting from the fact th= at other std components behave this way: containers, smart poi= nters, function, and only because perfect forwarding was not a= vailable at the time they were designed. However we anticipate that this ex= pectation (valid or not) could cause bugs in programs. Consider the followi= ng example:

optional<char> readChar(Stream str)
{
  optional<char> ans;

  if (str.buffered()) {
    ans =3D str.readBuffered();
    clearBuffer();
  }
  else if (!str.end()) {
    ans =3D str.readChar();
  }

  return ans;
}=20

This is so natural to expect that ans is not engaged until = we decide how we wan to engage it, that people will write this code. And in= the effect, if they cannod read the character, they will return an engaged= optional object with value '\0'. For these reasons we choose = to propose the former model.

The default constructor

This proposal provides a default constructor for optional<T>= that creates a disengaged optional. We find this feature convenient= for a couple of reasons. First, it is because this behaviour is intuitive = as shown in the above example of function readChar. It avoids = a certain kind of bugs. Also, it satisfies other expectations. If I declare= optional<T> as a non-static member, without any initia= lizer, I may expect it is already initialized to the most natural, disengag= ed, state regardless of whether T is DefaultConstructibl= e or not. Also when declaring a global object, one could expect that= default constructor would be initialized during static-initialization (thi= s proposal guarantees that). One could argue that the tagged constructor co= uld be used for that puropse: 

optional<int> global =3D nullopt;

struct X
{
  optional<M> m =3D nullopt;
};

However, sometimes not providing the tag may be the result of an inadver= tent omission rather than concious decision. Because of our default constru= ctor semantics we have to reject the initialization scheme that uses a perf= ect forwarding constructor. Even if this is fine, one could argue that we d= o not need a default constructor if we have a tagged constructor. We find t= his redundancy convenient. For instance, how do you resize a vector&l= t;optional<T>> if you do not have the default constructor? = You could type:

vec.resize(size, nullopt);

However, that causes first the creation of disengaged optional, and then= copying it multiple times. The use of copy constructor may incur run-time = overhead and not be available for non-copyable Ts. Also, it wo= uld be not possible to use subscript operator in maps that hold optional ob= jects.

Also, owing to this constructor, optional has a nice side-e= ffect feature: it can make "almost Regular" types fully = Regular if the lack of default constructor is the only thing they ar= e missing. For instance consider type Date for representing ca= lendar days: it is copyable movable, comparable, but is not DefaultCo= nstructible because there is no meaningful default date. However, optional<Date> is Regular with a meaningful n= ot-a-date state created by default.

Converting constructor (from T)

An object of type T is convertible to an engaged object of = type optional<T>:

optional<int> oi =3D 1; // works

This convenience feature is not strictly necessary because you can achie= ve the same effect by using tagged forwarding constructor:

optional<int> oi{emplace, 1};

If the latter appears too inconvenient, one can always use function make_optional described below:

=20 
optional<int> oi =3D make_optional(1);=20
auto oj =3D make_optional(1);=20

The implicit converting constructor comes in handy in case of optional f= unction arguments:

void fun(std::string s, optional<int> oi =3D nullopt);

fun("dog", 2);
fun("dog");
fun("dog", nullopt); // just to be explicit=20

It has been argued that the constructor from T should be ma= de explicit. It is not trivial to decide whether T should be c= onvertiblle to optional<T>. This is not a clear situatio= n where value of one type is stored in another type with greater resolution= , or the situation where the same abstract value is stored in a type with d= ifferent internal representation. On the other hand, given our conceptual m= odel, optional<T> can store all values of T= , so it is possible to apply a "lossless conversion". We decided to provide= the conversion, in order to (1) adhere to our conceptual model, and (2) to= enable the above convenience for function argument passing. The implicit c= onversion naturally implies that optional<T>'s can be co= mpared with T's. This is discussed further down.

At some point we considered the possibility to make this constructor con= ditionally explicit: make it explicit if T has an explicit cop= y/move constructor, and make it non-explicit if T has a normal= , non-explicit constructor. In the end, we find explicit copy constructor s= o unusual that we do not find it worthwile to addressing it at the expense = of compliicating the design.

Contextual conversion to bo= ol for checking engaged state

Objections have been risen to this decision. When using optional&l= t;bool>, contextual conversion to bool (used for che= cking the engaged state) might be confused with accessing the stored value.= while such mistake is possible, it is not precedent in the standard: types= bool*, unique_ptr<bool>, shared_ptr&= lt;bool> suffer from the same potential problem, and it was never= considered a show-stopper. Some have suggested that a special case in the = interface should be made for optional<bool> specializati= on. This was however rejected because it would break the generic use of optional.

Some have also suggested that a member function like is_initialize= d would more clearly indicate the intent than explicit conversion to= bool. However, we believe that the latter is a well establish= ed idiom in C++ comunity as well as in the C++ Standard Library, and = optional appears so fundamental a type that a short and familiar not= ation appears more appropriate. It also allows us to combine the constructi= on and checking for being engaged in a condition: =09

if (optional<char> ch =3D readNextChar()) {
  // ...
}

Using tag nullopt for indica= ting disengaged state

The proposed interface uses special tag nullopt to indicate= disengaged optional state. It is used for construction, assig= nment and relational operations. This might rise a couple of objections. Fi= rst, it introduces redundancy into the interface:

optional<int> opt1 =3D nullopt;=20
optional<int> opt2 =3D {};=20

opt1 =3D nullopt;
opt2 =3D {};

if (opt1 =3D=3D nullopt) ...
if (!opt2) ...
if (opt2 =3D=3D optional<int>{}) ...

On the other hand, there are usages where the usage of nullopt cannot be replaced with any other convenient notation:

void run(complex<double> v);
void run(optional<string> v);

run(nullopt);              // pick the second overload
run({});                   // ambiguous

if (opt1 =3D=3D nullopt) ...   // fine
if (opt2 =3D=3D {}) ...        // illegal

bool is_engaged( optional<int> o)
{
  return bool(o);          // ok, but unclear
  return o !=3D nullopt;     // familiar
}

While some situations would work with {} syntax, using nullopt makes the programmer's intention more clear. Compare these= :

optional<vector<int>> get1() {
  return {};
}

optional<vector<int>> get2() {
  return nullopt;
}

optional<vector<int>> get3() {
  return optional<vector<int>>{};
}

The usage of nullopt is also a consequence of the adapted m= odel for optional: a discriminated union of T and nullop= t_t. Also, a similar redundancy in the interface already exists in a= number of components in the standard library: unique_ptr, shared_ptr, function (which use literal nullpt= r for the same purpose); in fact, type requirements NullablePo= inter require of types this redundancy.

Name "nullopt" has been chosen because it clearly indicates that we are = interested in creating a null (disengaged) optional<T> (= of unspecified type T). Other short names like "null", "naught= ", "nothing" or "none" (used in Boost.Optional library) were rejected becau= se they were too generic: they did not indicate unambiguously that it was <= code>optional<T> that we intend to create. Such a generic tag = nothing could be useful in many places (e.g., in types like variant<nothing_t, T, U>), but is outside the scope of thi= s proposal.

=20

Note also that the definition of tag struct nullopt is more= complicated than that of other, similar, tags: it has explicitly deleted d= efault constructor. This is in order to enable the reset idiom (opt2 = =3D {};), which would otherwise not work because of ambiguuity when = deducing the right-hand side argument.

Why not nullptr

One could argue that since we have keyword nullptr, which a= lready indicates a 'null-state' for a number of Standard Library types, not= necessarily pointers (class template function), it could be e= qually well used for optional. In fact, the previous revision = of this proposal did propose nullptr, however there are certai= n difficulties that arise when the null-pointer literal is used.

First, the interface of optional is already criticized for = resembling too much the interface of a (raw or smart) pointer, which incorr= ectly suggests external heap storage and shallow copy and comparison semant= ics. The "ptr" in "nullptr" would only increase this confusion. While std::function is not a pointer either, it also does not provide a c= onfusing operator->, or equality comparison, and in case it= stores a function pointer it does shallow copying.

Second, using literal nullptr in optional woul= d make it impossible to provide some of the natural and expected initializa= tion and assignment semantics for types that themselves are nullable:

  • optional<int*>,
  • optional<const char*>,
  • optional<M C::*>,
  • optional<function<void(int)>>,
  • optional<NullableInteger>,
  • optional<nullptr_t>.

Should the following initialization render an engaged or a disengaged op= tional?

optional<int*> op =3D nullptr;

One could argue that if we want to initialize an engaged optional we sho= uld indicate that explicitly: 

optional<int*> op{emplace, nullptr};

But this argument would not work in general. One of the goals of the des= ign of optional is to allow a seamless "optionalization" of fu= nction arguments. That is, given the folowing function signature:

void fun(T v) {
  process(v);
}

It should be possible to change the signature and the implementation to:= 

void fun(optional<T> v) {
  if (v) process(*v);
  else   doSthElse();
}

and expect that all the places that call function fun are n= ot affected. But if T happens to be int* and we o= ccasionally pass value nullptr to it, we will silently change = the intended behavior of the refactoring: because it will not be the pointe= r that we null-initialize anymore but a disengaged optional.

Note that this still does not save us from the above problem with refact= oring function fun in case where T happens to be = optional<U>, but we definately limit the amount of surpr= ises.

In order to avoid similar problems with tag nullopt, instan= tiating template optional with types nullopt_t an= d emplace_t is prohibitted.

There exist, on the other hand, downsides of introducing a special token= in place of nullptr. The number of ways to indicate the 'null= -state' for different library components will grow: you will have NUL= L, nullptr, nullopt. New C++ programmers w= ill ask "which of these should I use now?" What guidelines should be provid= ed? Use only nullptr for pointers? But does it mean that we sh= ould use nullopt for std::function? Having only o= ne way of denoting null-state, would make the things easier, even if "ptr" = suggests a pointer.

Why not a tag dependent on T?

It has been suggested that instead of 'typeless' nullopt a = tag nested in class optional be used instead:

optional<int> oi =3D optional<int>::nullopt;

This has several advantages. Namespace std is not polluted = with an additional optional-specific name. Also, it resolves c= ertain ambiguities when types like optional<optional<T>= ;> are involved:

optional<optional<int>> ooi =3D optional<int>::nullo=
pt;           // engaged
optional<optional<int>> ooj =3D optional<optional<int>=
>::nullopt; // disengaged

void fun(optional<string>);
void fun(optional<int>);

fun(optional<string>::nullopt); // unambiguous: a typeless nullop=
t would not do=20

Yet, we choose to propose a typeless tag because we consider the above p= roblems rare and a typeless tag offers a very short notation in other cases= :

optional<string> fun()
{
  optional<int> oi =3D nullopt;  // no ambiguity
  oi =3D nullopt;                // no ambiguity
  // ...
  return nullopt;              // no ambiguity
}

If the typeless tag does not work for you, you can always use the follow= ing construct, although at the expense of invoking a (possibly elided) move= constructor:

=20 
optional<optional<int>> ooi =3D optional<int>{};    =
       // engaged
optional<optional<int>> ooj =3D optional<optional<int>=
>{}; // disengaged

void fun(optional<string>);
void fun(optional<int>);

fun(optional<string>{}); // unambiguous=20

Accessing the contained value

It was chosen to use indirection operator because, along with explicit c= onversion to bool, it is a very common pattern for accessing a= value that might not be there: 

if (p) use(*p);

This pattern is used for all sort of pointers (smart or dumb), and it cl= early indicates the fact that the value may be missing and that we return a= reference rather than a value. The indirection operator has risen some ob= jections because it may incorrectly imply that optional is a (= possibly smart) pointer, and thus provides shallow copy and comparison sema= ntics. All library components so far use indirection operator to return an = object that is not part of the pointer's/iterator's value. In contrast, optional indirects to the part of its own state. We do not consid= er it a problem in the design; it is more like an unprecedented usage of in= direction operator. We believe that the cost of potential confusion is ove= rweighed by the benefit of an easy to grasp and intuitive interface for acc= essing the contained value.

We do not think that providing an implicit conversion to T = would be a good choice. First, it would require different way of checking f= or the empty state; and second, such implicit conversion is not perfect and= still requires other means of accessing the contained value if we want to = call a member function on it.

Using the indirection operator for a disengaged object is an undefined b= ehavior. This behavior offers maximum runtime performance. In addition to i= ndirection operator, we provide member function value that ret= urns a reference to to the contained value if one exists or throws an excep= tion (derived from logic_error) otherwise:

void interact()
{
  std::string s;
  cout << "enter number ";
  cin >> s;
  optional<int> oi =3D str2int(s);
 =20
  try {
    process_int(oi.value());
  }
  catch(bad_optional_access const&) {
    cout << "this was not a number";
  }
}

Relational operators

One of the design goals of optional is that objects of type= optional<T> should be valid elements in STL containers = and usable with STL algorithms (at least if objects of type T= are). Equality comparison is essential for optional<T> = to model concept Regular. C++ does not have concepts, but bein= g regular is still essential for the type to be effectively used with STL. = Ordering is essential if we want to store optional values in ordered associ= ative containers. A number of ways of including the disengaged state in com= parisons have been suggested. The ones proposed, have been crafted such tha= t the axioms of equivalence and strict weak ordering are preserved: disenga= ged optional<T> is simply treated as an additional and u= nique value of T equal only to itself; this value is always co= mpared as less than any value of T:

optional<unsigned> o0{0};
optional<unsigned> o1{1};
optional<unsigned> oN{nullopt};

assert (oN < o0);
assert (o0 < o1);
assert (!(oN  < oN));
assert (!(o1 < o1));

assert (oN !=3D o0);
assert (o0 !=3D o1);
assert (oN =3D=3D oN);
assert (o0 =3D=3D o0);

Given that both nullopt_t and T are implicitly= convertible to optional<T>, this implies the existence = and semantics of mixed comparison between optional<T> an= d T, as well as between optional<T> and nullopt_t:

assert (oN =3D=3D nullopt);
assert (o0 !=3D nullopt);
assert (oN !=3D 1);
assert (o1 =3D=3D 1);

assert (oN < 1);
assert (o0 > nullopt);

Although it is difficult to imagine any practical use case of ordering r= elation between optional<T> and nullopt_t, = we still provide it for completness's sake

The mixed relational operators, especially these representing order, bet= ween optional<T> and T have been accused of= being dangerous. In code examples like the following, it may be unclear if= the author did not really intend to compare two T's. 

auto count =3D get_optional_count();
if (count < 20) {}                        // or did you mean: *count=
 < 20 ?
if (count =3D=3D nullopt || *count < 20) {}   // verbose, but unambi=
guous

Given that optional<T> is comparable and implicitly c= onstructible from T, the mixed comparison is there already. We= would have to artificially create the mixed overloads only for them to cau= se controlled compilation errors. A consistent approach to prohibiting mixe= d relational operators would be to also prohibit the convesion from T= or to also prohibit homogenous relational operators for optio= nal<T>; we do not want to do either, for other reasons discuss= ed in this proposal. Also, mixed relational operations are available in Boo= st.Optional and were found useful by the users. Mixed operators come as som= ething natural when we consider the model "T with one addition= al value".

For completeness sake, we also provide ordering relations between = optional<T> and nullopt_t, even though we see no = practical use case for them:

bool test(optional<int> o)
{
  assert (o >=3D nullopt);    // regardless of o's state
  assert (!(o < nullopt));  // regardless of o's state
  assert (nullopt <=3D o);    // regardless of o's state=20
  return (o > nullopt);     // o !=3D nullopt is cleaner
}

This is similar to comparing values of type unsigned int wi= th 0:

bool test(unsigned int i)
{
  assert (i >=3D 0);          // regardless of i's state
  assert (0 <=3D i);          // regardless of i's state
  return (i > 0);           // i !=3D 0 is cleaner
}

There exist two ways of implementing operator> for optio= nal objects:

bool operator>(const optional<T>& x, const optional<T&=
gt;& y)
{
  return (!x) ? false : (!y) ? true : *x > *y;  // use T::operator&g=
t;
}

bool operator>(const optional<T>& x, const optional<T>&a=
mp; y)
{
  return y < x;                                 // use optional<T=
>::operator<
}

In case T::operator> and T::operator< ar= e defined consistently, both above implementations are equivalent. If the t= wo operators are not consistent, the choice of implementation makes a diff= erence. For homogenous relational operations (between two optional<= ;T>s), we chose the former specification. That is, T::opera= tor> may not even be defined if order for optional<T>= ::operator< to work. This is consistent with a similar choice for= std::tuple. For heterogenous relational operations (between <= code>optional<T> and T), we choose the latter spe= cification. There is no precedent for mixed relops in the Standard Library,= so we do not feel we are making it wrong. The latter specification is more= close to the model "optional<T> is like T.= " For homogenous rel-ops we want to stick to the rules employed by the Stan= dard.

Resetting the optional value

Assigning the value of type T to optional<T> object results in doing two different things based on whether the opti= onal object is engaged or not. If optional object is engaged, the contained= value is assigned a new value. If optional object is disengaged, it become= s engaged using T's copy/move constructor. This behavior is ba= sed on a silent assumption that T's copy/move constructor is c= opying a value in a similar way to copy/move assignment. A similar logic ap= plies to optional<T>'s copy/move assignment, although th= e situation here is more complicated because we have two engaged/disengaged= states to be considered. This means that optional<T>'s = assignment does not work (does not compile) if T is not assign= able:

optional<const int> oi =3D 1;  // ok
oi =3D 2;                      // error=20
oi =3D oi;                     // error=20
oi =3D nullopt;                // ok

There is an option to reset the value of optional object without resorti= ng to T's assignment:

optional<const int> oj =3D 1;  // ok
oj.emplace(2);               // ok=20

Function emplace disengages the optional object if it is en= gaged, and then just engages the object anew by copy-constructing the conta= ined value. It is similar to assignment, except that it is guaranteed not t= o use T's assignment and provides only a basic exception saget= y guarantee. In contrast, assignment may provide a stronger guarantee if T's assignment does.

To sumarize, this proposal offers three ways of assigning a new containe= d value to an optional object:

optional<int> o;
o =3D make_optional(1);         // copy/move assignment
o =3D 1;                        // assignment from T
o.emplace(1);                 // emplacement=20

The first form of assignment is required to make optional a= regular object, useable in STL. We need the second form in order to reflec= t the fact that optional<T> is a wrapper for T and hence it should behave as T as much as possible. Also,= when optional<T> is viewed as T with one a= dditional value, we want the values of T to be directly assign= able to optional<T>. In addition, we need the second for= m to allow the interoperability with function std::tie as show= n above. The third option is required to be able to reset an optional non-a= ssignable T.

=20

Tag emplace

This proposal provides an 'in-place' constructor that forwards (perfectl= y) the arguments provided to optional's constructor into the c= onstructor of T. In order to trigger this constructor one has = to use the tag struct emplace. We need the extra tag to disamb= iguate certain situations, like calling optional's default con= structor and requesting T's default construction:

optional<Big> ob{emplace, "1"}; // calls Big{"1"} in place (=
no moving)
optional<Big> oc{emplace};      // calls Big{} in place (no movin=
g)
optional<Big> od{};             // creates a disengaged optional<=
/em>

The name, suggested by Alberto Ganesh Barbati, is consistent with member= functions of containers (and optional itself), which also ind= icate similar purpose. On the other hand, it may appear uncomfortable that = emplace becomes overloaded in std: it is now a me= mber function in many container type as well as a tag. If this is considere= d a serious issue, the tag could be renamed to in_place.

=20

Requirements on T

Class template optional imposes little requirements on T: it has to be either an lvalue reference type, or a complete obj= ect type satisfying the requirements of Destructible. It is th= e particular operations on optional<T> that impose requi= rements on T: optional<T>'s move constructo= r requires that T is MoveConstructible, opt= ional<T>'s copy constructor requires that T is CopyConstructible, and so on. This is because optional<= T> is a wrapper for T: it should resemble T as much as possible. If T is EqualityComparable then (and only then) we expect optional<T> to be EqualityComparable.

Optional references

In this revision, optional references are presented as an auxiliary prop= osal. The intention is that the Committee should have an option to accept o= ptional values without optional references, if it finds the latter concept = inacceptable. Users that in generic contexts require to also store optional= lvalue references can achieve this effect, even without direct support for= optional references, with a bit of meta-programming. 

template <class T>
struct generic
{
  typedef T type;
};

template <class U>
struct generic<U&>
{
  typedef std::reference_wrapper<U> type;
};

template <class T>
using Generic =3D typename generic<T>::type;

template <class X>
void generic_fun()
{
  std::optional<Generic<X>> op;
  // ...
}

Although the behavior of such "emulated" optional references will be sli= ghtly different than that of "normal" optional references.

=20

Exception specifications

First draft of this revision required an aggressive usage of conditional= noexcept specifications for nearly every, member- or non-memb= er-, function in the interface. For instance equality comparison was to be = declared as:

template <class T>
  bool operator=3D=3D(const optional<T>& lhs, const optional<T=
>& rhs)
  noexcept(noexcept(*lhs =3D=3D *rhs));

This was based on one of our goals: that we want optional<T>= to be applicable wherever T is applicable in as many s= ituations as reasonably possible. One such situation occurs where no-throw = operations of objects of type T are used to implement a strong= exception safety guarantee of some operations. We would like objects of ty= pe optional<T> to be also useable in such cases. However= , we do not propose this aggressive conditional no-throw guarantees at this= time in order for the proposed library component to adhere to the current = Library guidelines for conditional noexcept: it is currently o= nly used in move constructor, move assignment and swap. One ex= ception to this rule, we think could be made for optional's move constructo= r and assignment from type T&&, however we still do no= t propose this at this time in order to avoid controversy.

Constructors and mutating functions that disengage an optional object ar= e required to be noexcept(true): they only call T= 's destructor and impose no precondition on optional object's or contained = value's state. The same applies to the observers that check the disengaged/= engaged state.

The observers that access the contained value — operator* and operator-> — are not declared as noexc= ept(true) even though they have no good reason to throw. This is bec= ause they impose a precondition that optional object shall be engaged, and = as per observations from N3248[6], library vendors may need to u= se exceptions to test if the implementation has all the necessary precondit= ion-checking code inside. These observer functions are still required not t= o throw exceptions.

In general, operations on optional objects only throw, when operations d= elegated to the contained value throw.

Making optional a literal = type

We propose that optional<T> be a literal type for tri= vially destructible T's.

constexpr optional<int> oi{5};
static_assert(oi, "");            // ok
static_assert(oi !=3D nullopt, ""); // ok
static_assert(oi =3D=3D oi, "");      // ok
int array[*oi];                   // ok: array of size 5

Making optional<T> a literal-type in general is impos= sible: the destructor cannot be trivial because it has to execute an operat= ion that can be conceptually described as:

~optional() {
  if (is_engaged()) destroy_contained_value();
}

It is still possible to make the destructor trivial for T's= which provide a trivial destructor themselves, and we know an efficient im= plementation of such optional<T> with compile-time inter= face — except for copy constructor and move constructor — is po= ssible. Therefore we propose that for trivially destructible T= 's all optional<T>'s constructors, except for move and c= opy constructors, as well as observer functions are constexpr.= The sketch of reference implementation is provided in this proposal.

= =20

Moved-from state

When a disengaged optional object is moved from (i.e., when it is the so= urce object of move constructor or move assignment) its state does not chan= ge. When an engaged object is moved from, we move the contained value, but = leave the optional object engaged. A moved-from contained value is still va= lid (although possibly not specified), so it is fine to consider such optio= nal object engaged. An alternative approach would be to destroy the contain= ed value and make the moved-from optional object disengaged. However, we do= not propose this for performance reasons.

In contexts, like returning by value, where you need to call the destruc= tor the second after the move, it does not matter, but in cases where you r= equest the move explicitly and intend to assign a new value in the next ste= p, and if T does not provide an efficient move, the chosen app= roach saves an unnecessary destructor and constructor call:

optional<array<Big, 1000>> oo =3D ... // array doesn't=
 have efficient move
op =3D std::move(oo);
oo =3D std::move(tmp);

The following is even more compelling reason. In this proposal std= ::optional<int> is allowed to be implemented as a Trivia= llyCopyable type. Therefore, the copy constructor of type std:= :array<std::optional<int>, 1000> can be implemented usin= g memcpy. With the additional requirement that optional<= /code>'s move constructor should not be trivial, we would be preventing the= described optimization.

The fact that the moved-from optional is not disengaged may look "uncomf= ortable" at first, but this is an invalid expectation. The requirements of = library components expressed in 17.6.5.15 (moved-from state of library type= s) only require that moved-from objects are in a valid but unspecified stat= e. We do not need to guarantee anything above this minimum.

IO operations

The proposed interface for optional values does not contain IO operation= s: operator<< and operator>>. While w= e believe that they would be a useful addition to the interface of optional= objects, we also observe that there are some technical obstacles in provid= ing them, and we choose not to propose them at this time.

One can imagine a couple of ways in which IO-operations for any streamab= le type T could be expected to work. The differences are mostl= y the consequence of different conceptual models of optional types, as well= as different use cases that programmers may face. Below we list the possib= le ways of outputting the value of optional object.

  1. Output the contained value if engaged; otherwise enter an undefined beh= aviour (as programmer error).
  2. Output the contained value if engaged; otherwise output nothing.
  3. Output the contained value if engaged; otherwise output some special se= quence of characters.
  4. Output something like "OPT[v]", where v represents the contained value, if engaged; otherwise outp= ut something like "OPT[]".

The first option is a consequence of the model where optional<T= > is a T with deferred initialization, but which is = still initialized before first usage. This is not the model that we advocat= e, so this behavior of operator<< is rejected. However t= his behavior can be achieved by accessing the contained value of optional o= bject on each usage:

optional<int> oi;
initialize(oi);
cin >> (*oi);
cout << (*oi);

The second option appears useful in certain contexts, where we want opti= onal objects to indicate some supplementary, often missing, information: 

struct FlatNumber {
  unsigned number_;
  optional<char> letter_;
};

ostream& operator<<( ostream& out, FlatNumber n ) {
  return out << n.number_ << n.letter_;
}

// outputs "10", "11", "11A", ...=20

However, in general the results would be ambiguous. Does output "1=  0" indicate two engaged optional<int>s, or = three, one of which (which one?) is disengaged, or 77 optional<int= >s? Or are these perhaps two ints? Also, It is not p= ossible to implement a consistent operator>> in this cas= e. It may not be a problem itself, and providing only one operator is not a= precedent in the standard (consider std::thread::id); alterna= tively, operator>> could be implemented inconsistently: = by simply calling T's operator>>. =20

=20

The third choice appears attractive at first glance, but there is no goo= d representation for the special sequence that would produce no ambiguities= .. Whatever sequence we choose, it is also a valid representtion of st= d::string; thus if we need to interpret the special sequence, say "~~~" as optional<string>, we do not know if = it is a disengaged object, or engaged one with contained value of "~~= ~". On the other hand, some people have argued that this ambiguity i= s worth the usefulness of a simple tool for logging.

While the fourth choice presented above still comes with some similar am= biguities, it is posssible to implement a variant thereof that is not ambig= uous. Such solution has been implemented in Boost.Tuple library[5]: user has to register a sequence of letters that represent "an opening b= racket" of the optional object's contained value, and similarly register an= another sequence for representing a "closing bracket." This would be the u= ser's responsibility to make sure that the chosen sequences are unambiguous= , if default sequences (e.g., "[" and "]") do not= suffice. However, this solution is not without certain controversy.

Currently all streamable types in the library have a nice property that = string representation that is streamed out or read in is similar to the for= mat of literals in C++ used to initialize variables. Thus, whatever you typ= e into the console that you intend your program to read, could be equally w= ell typed directly in the C++ code as a literal — of course, to certa= in extent. The text that the program requires of users to read and type is = simply nice.

This controversy is characteristic not only of optional. Li= brary components like containers, pairs, tuples face the same issue. At pre= sent IO operations are not provided for these types. Our preference for optional is to provide an IO solution compatible with this for co= ntainers, pairs and tuples, therefore at this point we refrain from proposi= ng a solution for optional alone.

Type requirements NullableProxy

As already mentioned, the primary purpose of optional object is to check= if they contain a value and if so, to provide access to this value. We obs= erve that a similar functionalit is offered by raw and smart pointers, exce= pt for the "contains" part: pointers do not contain the value they point to= .. Nonetheless, optional objects and pointers have enough things in common t= hat certain class of generic functions can be written that can be used with= either. We call the identified concept NullableProxy. Basical= ly, the concept indicates that a type is a 'proxy' for another type. The op= erations allowed are: checking if there exists an object that our proxy can= indirect us to and the indirection operation. The operations can be summar= ized by the following use-case:

temmplate <class NullableProxy>
void test(NullableProxy&& np)
{
  if (np)              // 'has-object' check
    auto&& obj =3D *np;  // object access
  if (!np) {}          // 'doesn't have object'
}

These requirements are sufficient to specify a couple of generic functio= ns (not proposed), like the one below: 

template <typename NullableProxy>
// enable_if: decltype(*declval<NullableProxy>()) is EqualityComp=
arable
bool equal_pointees( const NullableProxy& x, const NullableProxy& y=
 )
{
  return bool(x) !=3D bool(y) ? false : ( x ? *x =3D=3D *y : true );
}

This is exactly the logic for the equality comparison of optional values= , and could be used as an implementation of optional<T>::operat= or=3D=3D. A similar algorithm for less-than comparison can be specif= ied. The third example is function value_or discussed below. A= nother example is function as_ptr discussed below, for providi= g raw pointer access to a possibly-null proxied value.

Requirements NullableProxy overlap with requirements = NullablePointer. Their common part could be extracted to separate re= quirements, say Nullable, but these requirements are to small = to be useful alone for anything.

We do not propose to add NullableProxy to Library at this t= ime, as the usage base may be to small for justifying the change. It may pr= ove a useful addition in the future.

Function value_or

This function template returns a value stored by the optional object if it is engaged, and if not, it falls back to the default value = specified in the second argument. It used to be called get_value_or in the previous revisions, but we decided to rename it, as a conseque= nce of disscussions, so that it is similar to another new member function <= code>value. This method for specifying default values on the fly rat= her than tying the default values to the type is based on the observation t= hat different contexts or usages require different default values for the s= ame type. For instance the default value for int can be 0 or -= 1. The callee might not know what value the caller considers special, so it= returns the lack of the requested value explicitly. The caller may be bett= er suited to make the choice what special value to use.

optional<int> queryDB(std::string);
void setPieceCount(int);
void setMaxCount(int);

setPieceCount( queryDB("select piece_count from ...").value_or(0) );
setMaxCount( queryDB("select max_count from ...").value_or(numeric_limits&l=
t;int>::max()) );

The decision to provide this function is controversial itself. As pointe= d out by Robert Ramey, the goal of the optional is to make the= lack of the value explicit. Its syntax forces two control paths; therefore= we will typically see an if-statement (or similar branching i= nstruction) wherever optional is used. This is considered an i= mprovement in correctness. On the other hand, using the default value appea= rs to conflict with the above idea. One other argument against providing it= is that in many cases you can use a ternary conditional operator instead:<= /p> 

auto&& cnt =3D queryDB("select piece_count from ...");
setPieceCount(cnt ? *cnt : 0);

auto&& max =3D queryDB("select max_count from ...");
setMaxCount(max ? std::move(*max) : numeric_limits<int>::max());

However, in case optional objects are returned by value and immediately = consumed, the ternary operator syntax requires introducing an lvalue. This = requires more typing and explicit move. This in turn makes the= code less safe because a moved-from lvalue is still accessible and open fo= r inadvertent misuse.

There are reasons to make it a free-standing function. (1) It can be imp= lemented by using only the public interface of optional. (2) T= his function template could be equally well be applied to any type satisfyi= ng the requirements of NullableProxy. In this proposal, functi= on value_or is defined as a member function and only for optionals. Making a premature generalization would risk standardizi= ng a function with suboptimal performance/utility. While we know what detai= led semantics (e.g., the return type) value_or should have for= optional, we cannot claim to know the ideal semantics for any= NullableProxy. Also, it is not clear to us if this convenienc= e function is equally useful for pointers, as it is for optional objects. B= y making value_or a member function we leave the room for this= name in namespace std for a possible future generalization.

The second argument in the function template's signature is not T<= /code> but any type convertible to T:

template <class T, class V>=20
  typename decay<T>::type optional<T>::value_or(V&& v) const&;
template <class T, class V>=20
  typename decay<T>::type optional<T>::value_or(V&& v) &&;

This allows for a certain run-time optimization. In the following exampl= e:

optional<string> op{"cat"};
string ans =3D op.value_or("dog");

Because the optional object is engaged, we do not need the fallback valu= e and therefore to convert the string literal "dog" into type = string.

It has been argued that the function should return by constant reference= rather than value, which would avoid copy overhead in certain situations:<= /p> 

void observe(const X& x);

optional<X> ox { /* ... */ };
observe( ox.value_or(X{args}) );    // unnecessary copy

However, the benefit of the function value_or is only visib= le when the optional object is provided as a temporary (without the name); = otherwise, a ternary operator is equally useful:

optional<X> ox { /* ... */ };
observe(ox ? *ok : X{args});            // no copy

Also, returning by reference would be likely to render a dangling refere= nce, in case the optional object is disengaged, because the second argument= is typically a temporary:

optional<X> ox {nullopt};
auto&& x =3D ox.value_or(X{args});
cout << x;                              // x is dangling!

There is also one practical problem with returning a reference. The func= tion takes two arguments by reference: the optional object and the default = value. It can happen that one is deduced as lvalue reference and the other = as rvalue reference. In such case we would not know what kind of reference = to return. Returning lvalue reference might prevent move optimization; retu= rning an rvalue reference might cause an unsafe move from lvalue. By return= ing by value we avoid these problems by requiring one unnecessary move in s= ome cases.

We also do not want to return a constant lvalue reference because that w= ould prevent a copy elision in cases where optional object is returned by v= alue.

It has also been suggested (by Luc Danton) that function optional&= lt;T>::value_or<V> should return type decay<common= _type<T, V>::type>::type rather than decay<T>::= type. This would avoid certain problems, such as loss of accuracy on= arithmetic types:

// not proposed
std::optional<int> op =3D /* ... */;
long gl =3D /* ... */;

auto lossless =3D op.value_or(gl);   // lossless deduced as long rather=
 than int

However, we did not find many practical use cases for this extension, so= we do not propose is at this time.

Together with function value, value_or makes a= set of similarly called functions for accessing the contained value that d= o not cause an undefined behavior when invoked on a disengaged optional (at= the expense of runtime overhead). They differ though, in the return type: = one returns a value, the other a reference.

One other similar convenience function has been suggested. Sometimes the= default value is not given, and computing it takes some time. We only want= to compute it, when we know the optional object is disengaged:

optional<int> oi =3D /* ... */;

if (oi) {
  use(*oi);
}
else {
  int i =3D painfully_compute_default();
  use(i);
}

The solution to that situation would be another convenience function whi= ch rather taking a default value takes a callable object that is capable of= computing a default value if needed:

use( oi.value_or_call(&painfully_compute_default) );      =20
// or
use( oi.value_or_call([&]{return painfully_compute_default();} );

We do not propose this, as we prefer to standardize the existing practic= e. Also, it is not clear how often the above situations may occur, and the = tool prove useful.

Function make_optional=

We also propose a helper function make_optional. Its semant= ics is closer to that of make_pair or make_tuple = than that of make_shared. You can use it in order for the type= of the optional to be deduced:

int i =3D 1;
auto oi =3D make_optional(i);          // decltype(oi) =3D=3D optional&=
lt;int>

This may occasionally be useful when you need to pick the right overload= and not type the type of the optional by hand: 

void fun(optional<complex<double>>);
void fun(Current);                   // complex is convertible to Curre=
nt

complex<double> c{0.0, 0.1};
fun(c);                              // ambiguous
fun({c});                            // ambiguous
fun(make_optional(c));               // picks first overload

This is not very useful in return statements, as long as the converting = constructor from T is implicit, because you can always use the= brace syntax:

optional<complex<double>> findC()
{
  complex<double> c{0.0, 0.1};
  return {c};
}

make_shared-like function does not appear to be useful at a= ll: it is no different than manually creating a temporary optional object:<= /p> 

// not proposed
fun( make_optional<Rational>(1, 2) );
fun( optional<Rational>{1, 2} );     // same as above

It would also not be a good alternative for tagged placement constructor= , because using it would require type T to be MoveConstr= uctible:

// not proposed
auto og =3D make_optional<Guard>("arg1"); // ERROR: Guard is not =
MoveConstructible

Such solution works for shared_ptr only because its copy co= nstructor is shallow. One useful variant of shared_ptr-like make_optional would be a function that either creates an engaged= or a disengaged optional based on some boolean condition:

// not proposed
return make_optional_if<Rational>(good(i) && not_bad(j), i, j=
);

// same as:
if (good(i) && not_bad(j)) {
  return {i, j};
}
else {
  return nullopt;
}

// same as:
optional<Rational> or =3D nullopt;
if (good(i) && not_bad(j)) or.emplace(i, j);
return or; // move-construct on return

Since this use case is rare, and the function call not that elegant, and= a two-liner alternative exists, we do not propose it.

Raw pointer interface

It has been suggested by a couple of people that optional a= lso provides a function that returns a raw pointer: nullptr if= optional is engaged, otherwise a pointer to the contained value. This is s= imilar to member function get in smart pointers and function <= code>target in std::function:

auto optional<T>::as_ptr() -> value_type*
{
  return bool(*this) ? addressof(**this) : nullptr;
}

It might be convenient when trying to use optional with old= er libraries that used raw pointers to represent optional values. It was ob= served, however, that different library components start to diverge from on= e another in terms of the interface: smart pointers have get, = function has target it is not clear which name sh= ould optional use. The semantics of either are different than = these of optional<T>::as_ptr. Smart pointers store a raw= pointer that can be returned. In optional it has to be built.= Function target requires specifying a pointer type. It was al= so suggested that a generic function applicable uniformly to all smart poin= ters and optional would be a better choice. However, when trea= ting pointers and optional uniformly, the situation becomes tr= icky because unlike all pointers, optional contains = the object it indirects to and needs to propagate constness when providing = access to its contained value. 

template <typename NullableProxy>
auto as_ptr( NullableProxy&& x ) -> decltype(addressof(*std::forwar=
d<NullableProxy>(x)))
{
  return bool(x) ? addressof(*std::forward<NullableProxy>(x)) : nullp=
tr;
}

The convoluted type may be too tricky for a Library function, and a type= traits for NullableProxy may be needed. This appears to be to= o much changes compared with the limited functionality the function would o= ffer. We chose not to propose it. Programmers who need it for optiona= l can easily implement it as indicated above. If the feature turns o= ut to be necessary, it can be added in the future in a backwards-compatible= manner.

"Copy initialization forwarding"

At some point the following goal was considered for optional; it is the property that could informally be called "copy initialization = forwarding". It is somewhat similar to the one-argument version of perfect = forwarding constructor; i.e., if a given initializer can be used to copy-in= itialize objects of type T, it should also be possible to to u= se it to copy-initialize objects of type optional<T> wit= h the same samantics as initializing object of type T. This go= al cannot be achieved in 100% without severely compromising other design go= als. For instance, we cannot guarantee the following: 

T x =3D {};             // "{}" is the initializer; x is value-ini=
tialized
optional<T> ox =3D {};  // same initializer; contained value not =
initialized

assert (x =3D=3D *ox);    // not guaranteed!

Apart from this default initialization case, and a couple of others (con= cerning initializer-list), "copy initialization forwarding" could be provid= ed for optional.

Since optional<T> can be thought of as an "almost T", one could expect that if the following works:

void fun(std::string s);
fun("text");

the following should also work:

void gun(optional<std::string> s);
gun("text");

However, naively implementing a converting constructor would also enable= a non-explicit converting constructor from any type U to type= optional<T> for any type T. This would tur= n some types that are explicitly constructible into optional types that are= implicitly constructible. Consider: 

void explicit_conv( int * ptr ) {
  unique_ptr<int> v =3D ptr;           // ILLEGAL=20
}

void implicit_conv( int * ptr ) {
  optional<unique_ptr<int>> v =3D ptr; // LEGAL
}

In order to make the former example work on the one hand and to prevent = the problem with the latter example on the other, we considered a solution = that could be informally called a conditionally-explicit converting constru= ctor. We could achieve this by specifying two constructor templates with id= entical template and function parameters, one explicit and one non-explicit= , and make them mutually exclusive by means of SFINAE:

template <class U>=20
  // enable_if: Constructible<T, U&&> && !Convert=
ible<U&&, T>
  explicit optional<T>::optional(U&&);
  =20
template <class U>=20
  // enable_if: Convertible<U&&, T>
  optional<T>::optional(U&&);

Such concept-like behaviour as used above can be implemented in C++ with= type traits and enable_if. It was noted, however, that the ex= istence of such converting constructor would cause unexpected ambiguities i= n overload resolution. Consider the following scenario. We start from a wor= king program:

// library
void fun(string const& s);

// usage
fun("hello");

At some point we decide to add a second overload that accepts an optiona= l string:

// library
void fun(string const& s);
void fun(optional<string> const& s);   // new overload

// usage
fun("hello");                          // ERROR: ambiguity

Does it make sense to add an overload for optional rather than substitut= ing it for the original? It might be useful for performance reasons: if you= already have string it is cheaper to bind it directly to string const& than to create a temporary optional object and t= rigger the copy constructor of string:

// library
void fun(optional<string> const& s);   // only this fun

// usage
string s =3D "hello";
fun(s);                                // copy ctor invoked!

This example shows how an implicit conversion can cause an inadvertent a= nd unexpected (potentially expensive) copy constructor. For this reason we = do not propose a converting constructor from arbitrary type U.= (Although we do propose a converting constructor from T.)

Handling initializer_list<= /code>

Another feature worth considering is a "sequence constructor" (one that = takes initializer_list as its argument). It would be enabled (= in enable_if sense) only for these Ts that themse= lf provide a sequence constructor. This would be useful to fully support tw= o features we already mentioned above (but chose not to propose).

First, our goal of "copy initialization forwarding" for optional also needs to address the following usages of initializer_list<= /code>: 

vector<int> v =3D {1, 2, 4, 8};
optional<vector<int>> ov =3D {1, 2, 4, 8};

assert (v =3D=3D *ov);

This is not only a syntactical convenience. It also avoids subtle bugs. = When perfect forwarding constructor is implemented naively with one variadi= c constructor, optional vector initialization may render surprising result:= 

optional<vector<int>> ov =3D {3, 1};

assert (*ov =3D=3D vector{3, 1});    // FAILS!
assert (*ov =3D=3D vector{1, 1, 1}); // TRUE!

However this sequence constructor feature is incompatible with another o= ne: default constructor creating a disengaged optional. This is because, as= outlined in the former example, initializer {}, that looks li= ke 0-element list, is in fact interpretted as the request for value-initial= ization (default constructor call). This may hit programmers that use initi= alizer list in "generic" context:

template <class ...A> // enable_if: every A is int
void fwd(const A&&... a)
{
  optional<vector<int>> o =3D {a...};
  assert (bool(o)); // not true for empty a
}

If this feature were to be added, we would need to provide an assignment= from initializer list and variadic 'emplacement' constructor with the firs= t forwarded argument being initializer_list:

ov =3D {1, 2, 4, 8};

allocator<int> a;
optional<vector<int>> ou { emplace, {1, 2, 4, 8}, a };

assert (ou =3D=3D ov);

Since we are not proposing neither perfect forwarding constructor, nor t= he "copy initialization forwarding", we are also not proposing the sequence= constructor. However, in this proposal, the following constructs work:

optional<vector<int>> ov{emplace, {3, 1}};
assert (*ov =3D=3D vector{3, 1});

ov.emplace({3, 1});
assert (*ov =3D=3D vector{3, 1});

optional<optional<T= >>

The necessity to create a "double" optional explicitly does not occur of= ten. Such type may appear though in generic contexts where we create = optional<V> and V only happens to be option= al<T>. Some special behavior to be observed in this situation = is the following. When copy-initializing with nullopt, the "ou= termost" optional is initialized to disengaged state. Thus, changing functi= on argument from optional<T> to optional<option= al<T>> will silently break the code in places where the arg= ument passed to function happens to be of type nullopt_t:

// before change
void fun(optional<T> v) {
  process(v);
}

fun(nullopt); // process() called

// after change
void fun(optional<optional<T>> v) {
  if (v) process(*v);
  else   doSthElse();
}

fun(nullopt); // process() not called!

This issue would not arise if nullopt were T-s= pecific:

=20 
fun(optional<T>::nullopt);            // process() called
fun(optional<optional<T>>::nullopt);  // process() not call=
ed

Since T-dependent nullopt is not proposed, in = order to create an engaged optional containing a disengaged optional, one n= eeds to use one of the following constructs:

optional<optional<T>> ot {emplace};
optional<optional<T>> ou {emplace, nullopt};
optional<optional<T>> ov {optional<T>{}};

Also note that make_optional will create a "double" optiona= l when called with optional argument:

optional<int> oi;
auto ooi =3D make_optional(oi);
static_assert( is_same<optional<optional<int>>, decltype(ooi=
)>::value, "");

Conditional initialization to en= gaged state

It has been suggested, and in fact implemented in Boost.Optional, that <= code>optional shall have an another constructor with the first argum= ent of type bool. The value of this argument should be used to= determine whether the object should be disengaged, or engaged using the re= maining arguments. If we wanted to provide it in optional and = disampiguate the situations where the contained value is also initialized w= ith the first argument of type bool, it could be easily done b= y providing a yet another tag (similar to emplace_t):

bool doIt =3D false;
tr2::optional<string> opstr1{ tr2::only_if(doIt), 3, 'x' };=20
// disengaged

doIt =3D true;
tr2::optional<string> opstr2{ tr2::only_if(doIt), 3, 'x' };=20
// contained value is "xxx"

However, we do not see a practical use case for this usage. Undoubtedly,= it spares you from an explicit if-statement and a two-phase initialization= of the optional object, but then it appears obvious that at some time you = need to check the value of doIt anyway, because you do not eve= n know the state of the optional object. It is at that time that you may as= well decide to initialize the contained value:

optional<string> process( bool doIt )
{
  fun1(doIt);
  optional<string> optstr;
 =20
  if (doIt) {  // we ned an if to conditionally call fun2()
    fun2();
    optstr.emplace(3, 'x');
  }
 =20
  return optstr;
}

Also, even if you create optional as disengaged in the conditional const= ructor, you still have to compute the values of the arguments that you coul= d potentially use to initialize the contained value, so the two-phase initi= alization may look more attractive.

For these reasons we do not propose such conditional constructor at this= point. However, there appears to be no difficulty in adding it if we find = convincing use cases.

Proposed wording

Add new header in Table 14 (C++ library headers).

<= td><tuple> = <= td><map> = <unordered_map> <new> = =
Table 14 — C++ library headers
<algorithm> <fstream> <list> <ratio>
<array> <functional> <locale> <regex><typeindex>
<atomic> <future> <set> <typeinfo>
<bitset> <initializer_list> <memory> <sstream> <type_traits>
<chrono> <iomanip><mutex> <stack>
<codecvt> <ios> <stdexcept> = <unordered_set>
<complex> <iosfwd><numeric> <streambuf> <utility>
<condition_variable> <iostream>= <optional> &l= t;string> <valarray>
<dequeue> <istream><ostream> <strstream> <vector>
<exception> <iterator> <queue> <system_error>  
<forward_list> <limits><= /td> <random> <thread>  

After chapter 20.4 Tuples [tuple], insert a new paragraph. (Chapter [tem= plate.bitset] (Class template bitset) becomes 20.6.)

=20
=20

20.5 Optional objects = [optional]

20.5.1 In general [optional.general]

This subclause describes class template optional that repre= sents optional objects. An optional object for object types is an object that contains the storage for another object and manages th= e lifetime of this contained object. The contained object may be initialize= d after the optional object has been initialized, and may be destroyed befo= re the optional object has been destroyed. The initialization state of the = contained object is tracked by the optional object. An optional object = for lvalue reference types is an object capable of storing the address= of another object. The address stored by the optional object can be change= d or set to a value that does not represent a valid address.

=20

20.5.2 Header <optional> sy= nopsis [optional.synop]

namespace std {
namespace experimental {
  // 20.5.4, optional for=
 object types
  template <class T> class optional;

  // 20.5.5, In-place construction
  struct emplace_t{};
  constexpr emplace_t emplace{};

  // 20.5.6, Disengaged state indicat=
or
  struct nullopt_t{see below};
  constexpr nullopt_t nullopt(unspecified);
 =20
  // 20.5.7, class bad_op=
tional_access
  class bad_optional_access;

  // 20.5.8, Relational operators
  template <class T>
    constexpr bool operator=3D=3D(const optional<T>&, const optio=
nal<T>&);
  template <class T>
    constexpr bool operator!=3D(const optional<T>&, const optiona=
l<T>&);
  template <class T>
    constexpr bool operator<(const optional<T>&, const optiona=
l<T>&);
  template <class T>
    constexpr bool operator>(const optional<T>&, const optiona=
l<T>&);
  template <class T>
    constexpr bool operator<=3D(const optional<T>&, const opti=
onal<T>&);
  template <class T>
    constexpr bool operator>=3D(const optional<T>&, const opti=
onal<T>&);

  // 20.5.9, Comparison with nu=
llopt
  template <class T> constexpr bool operator=3D=3D(const optional<=
T>&, nullopt_t) noexcept;
  template <class T> constexpr bool operator=3D=3D(nullopt_t, const o=
ptional<T>&) noexcept;
  template <class T> constexpr bool operator!=3D(const optional<T&=
gt;&, nullopt_t) noexcept;
  template <class T> constexpr bool operator!=3D(nullopt_t, const opt=
ional<T>&) noexcept;
  template <class T> constexpr bool operator<(const optional<T&=
gt;&, nullopt_t) noexcept;
  template <class T> constexpr bool operator<(nullopt_t, const opt=
ional<T>&) noexcept;
  template <class T> constexpr bool operator<=3D(const optional<=
;T>&, nullopt_t) noexcept;
  template <class T> constexpr bool operator<=3D(nullopt_t, const =
optional<T>&) noexcept;
  template <class T> constexpr bool operator>(const optional<T&=
gt;&, nullopt_t) noexcept;
  template <class T> constexpr bool operator>(nullopt_t, const opt=
ional<T>&) noexcept;
  template <class T> constexpr bool operator>=3D(const optional<=
;T>&, nullopt_t) noexcept;
  template <class T> constexpr bool operator>=3D(nullopt_t, const =
optional<T>&) noexcept;

  // 20.5.10, Comparison with T
  template <class T> constexpr bool operator=3D=3D(const optional<=
T>&, const T&);
  template <class T> constexpr bool operator=3D=3D(const T&, cons=
t optional<T>&);
  template <class T> constexpr bool operator!=3D(const optional<T&=
gt;&, const T&);
  template <class T> constexpr bool operator!=3D(const T&, const =
optional<T>&);
  template <class T> constexpr bool operator<(const optional<T&=
gt;&, const T&);
  template <class T> constexpr bool operator<(const T&, const =
optional<T>&);
  template <class T> constexpr bool operator<=3D(const optional<=
;T>&, const T&);
  template <class T> constexpr bool operator<=3D(const T&, con=
st optional<T>&);
  template <class T> constexpr bool operator>(const optional<T&=
gt;&, const T&);
  template <class T> constexpr bool operator>(const T&, const =
optional<T>&);
  template <class T> constexpr bool operator>=3D(const optional<=
;T>&, const T&);
  template <class T> constexpr bool operator>=3D(const T&, con=
st optional<T>&);

  // 20.5.11, Specialized algorithms<=
/em>
  template <class T> void swap(optional<T>&, optional<T&=
gt;&) noexcept(see below);
  template <class T> constexpr optional<see below> mak=
e_optional(T&&);

  // 20.5.12, hash support
  template <class T> struct hash;
  template <class T> struct hash<optional<T>>;
} // namespace experimental
} // namespace std
=20

A program that necessitates the instantiation of template option= al for an lvalue reference or rvalue reference type, or for types emplace_t or nullopt_t, or a possibli cv-qualified = reference to types emplace_t or nullopt_t is ill-= formed.

20.5.3 Definitions [optional.defs]

=20

An instance of optional<T> is said to be diseng= aged if it has been default constructed, constructed or assigned with = a value of type nullopt_t, constructed or assigned with a dise= ngaged optional object of type optional<T>.

An instance of optional<T> is said to be engage= d if it has=20 been modified with member function emplace, constructed with= a value of type T, assigned a value of type T, c= opy-constructed from or assigned with an engaged optional object of type optional<T>.=20

=20

Being engaged or disengaged is part of the optional object's state. =20 =20 =20

20.5.4 optional for object typ= es [optional.object]

=20 
namespace std {
namespace experimental {

  template <class T>
  class optional
  {
  public:
    typedef T value_type;

    // 20.5.4.1, constructors
    constexpr optional() noexcept;
    constexpr optional(nullopt_t) noexcept;
    optional(const optional&);
    optional(optional&&) noexcept(see below);
    constexpr optional(const T&);
    constexpr optional(T&&);
    template <class... Args> constexpr explicit optional(emplace_t, A=
rgs&&...);
    template <class U, class... Args>
      constexpr explicit optional(emplace_t, initializer_list<U>, Arg=
s&&...);

    // 20.5.4.2, destructor
    ~optional();

    // 20.5.4.3, assignment
    optional& operator=3D(nullopt_t) noexcept;
    optional& operator=3D(const optional&);
    optional& operator=3D(optional&&) noexcept(see below);
    template <class U> optional& operator=3D(U&&);
    template <class... Args> optional& emplace(Args&&...)=
;
    template <class U, class... Args>
      optional& emplace(initializer_list<U>, Args&&...);

    // 20.5.4.4, swap
    void swap(optional&) noexcept(see below);

    // 20.5.4.5, observers
    constexpr T const* operator ->() const;
    T* operator ->();
    constexpr T const& operator *() const;
    T& operator *();
    constexpr explicit operator bool() const noexcept;
    constexpr T const& value() const;
    T& value();
    template <class U> constexpr T value_or(U&&) const&;
    template <class U> T value_or(U&&) &&;

  private:
    bool init; // exposition only
    T*   val;  // exposition only
  };

} // namespace experimental
} // namespace std

Engaged instances of optional<T> where T= is of object type shall contain a value of type T within its = own storage. This value is referred to as the contained value of t= he optional object. Implementations are not permitted to use additional sto= rage, such as dynamic memory, to allocate its contained value. The contain= ed value shall be allocated in a region of the optional<T> storage suitably aligned for the type T. Initializing the c= ontained value shall put the optional object into engaged state. Destroying= the contained value shall put the optional object into disengaged state.

Members init and val are= provided for exposition only. Implementations need not provide those membe= rs. init indicates whether the optional object's contained value has been initialized (and not yet destroyed); val points to (a possibly uninitialized) contained va= lue.

T shall be an object type and shall satisfy the requirement= s of Destructible (Table 24).

Throughout this subclause term direct-non-list-initialization i= s used to denote a direct-initialization that is not list-initialization.

20.5.4.1 Constructors [optional.object.ctor]
=20

constexpr optional<T>::optional() noexcept;
constexpr optional<T>::optional(nullopt_t) noexcept;

Effects:

Constructs a disengaged optional ob= ject.

Postconditions:

bool(*this) =3D=3D false.

Remarks:

No T object referenced is initializ= ed. For every object type T these constructors shall be = constexpr constructors (7.1.5).

=20

optional<T>::optional(const optional<T>& rhs);

Requires:

is_copy_constructible<T>::value is true.

Effects:

Constructs an optional object. If= bool(rhs) =3D=3D true initializes the contained va= lue as if direct-non-list-initializing an object of type T wit= h the expression *rhs.

Postconditions:

bool(rhs) =3D=3D bool(= *this).

Throws:

Whatever the execution of T's sele= cted constructor throws.

=20 =20

optional<T>::optional(optional<T> && rhs) noexcept(see below);

=20
Requires:

is_move_constructible<T>::value is true.

Effects:

Constructs an optional object. If= bool(rhs) =3D=3D true initializes the contained va= lue as if direct-non-list-initializing an object of type T wit= h the expression std::move(*rhs).

Postconditions:

bool(rhs) =3D=3D bool(= *this).

Throws:

Whatever the execution of T's sele= cted constructor throws.

Remarks:

The expression inside noexcept is= equivalent to:

is_nothrow_move_constructible<T>::value
=20

optional<T>::optional(const T& v);

=20
Requires:

is_copy_constructible<T>::value is true.

Effects:

Constructs an optional object by = direct-non-list-initializing the contained value with the expression = v.

Postconditions:

bool(*this) =3D=3D true.

Throws:

Whatever the execution of T's sele= cted constructor throws.

Remarks:

If T's selected constructor is a = constexpr constructor, this constructor shall be a const= expr constructor.

=20 =20

optional<T>::optional(T&& v);

=20
Requires:

is_move_constructible<T>::value is true.

Effects:

Constructs an optional object by = direct-non-list-initializing the contained value with the expression = std::move(v).

Postconditions:

bool(*this) =3D=3D true.

Throws:

Whatever the execution of T's sele= cted constructor throws.

Remarks:

If T's selected constructor is a = constexpr constructor, this constructor shall be a const= expr constructor.

=20 =20

template <class... Args> constexpr explicit optional(emplace_= t, Args&&... args);

=20
Requires:

is_constructible<T, Args&&..= ..>::value is true.

Effects:

Constructs an engaged optional ob= ject. Initializes the contained value as if constructing an object of type = T with the arguments std::forward<Args>(args)....

Postconditions:

bool(*this) =3D=3D true.

Throws:

Whatever the execution of T's cons= tructor selected for the initialization throws.

Remarks:

If T's constructor selected for t= he initialization is a constexpr constructor, this constructor= shall be a constexpr constructor.

template <class U, class... Args>
explicit optional(emplace_t, initializer_list<U> il, Arg= s&&... args);

=20
Requires:

is_constructible<T, initializer_list= <U>, Args&&...>::value is true.

Effects:

Constructs an engaged optional ob= ject. Initializes the contained value as if constructing an object of type = T with the arguments il, std::forward<Args>(arg= s)....

Postconditions:

bool(*this) =3D=3D true.

Throws:

Whatever the execution of T's cons= tructor selected for the initialization throws.

Remarks:

The function shall not participate in overload= resolution unless is_constructible<T, initializer_list<U>, = Args&&...>::value is true.

Remarks:

If T's constructor selected for t= he initialization is a constexpr constructor, this constructor= shall be a constexpr constructor.

20.5.4.2 Destructor [optional.object.dtor]
=20

=20 optional<T>::~optional();

=20
Effects:

If is_trivially_destructible<T>::v= alue !=3D true and bool(*this) =3D=3D true, calls val->T::~T().

Remarks:

If is_trivially_destructible<T>::v= alue =3D=3D true then this destructor shall be a trivial destructor.=

=20 =20 =20
20.5.4.3 Assignment [optional.object.assign]
=20 =20

optional<T>& optional<T>::operator=3D(nullopt_t) no= except;

Effects:

If bool(*this) =3D=3D true calls = val->T::~T() to destroy the contained value<= /em>; otherwise no effect.

Returns:

*this

Postconditions:

bool(*this) =3D=3D false.<= /p>

=20

optional<T>& optional<T>::operator=3D(const optiona= l<T>& rhs);

=20
Requires:

is_copy_constructible<T>::value is true and is_copy_assignable<T>::value is true.

Effects:

If init =3D=3D false &&am= p; rhs.init =3D=3D false, no effect. If init =3D=3D true && rhs.init =3D=3D false, destroys the c= ontained value by calling val->T::~T(). If init =3D=3D false && rhs.init =3D=3D true, constructs the contained value as if direct-non-list-initializing an = object of type T with *rhs. If <= var>init =3D=3D true && rhs.init =3D=3D true, assigns *rhs to the contained value.

Returns:

*this

Postconditions:

bool(rhs) =3D=3D bool(= *this).

Exception Safety:

If any exception is thrown values of = init and rhs.init remain un= changed. If an exception is thrown during the call to T's copy= constructor, no effect. If an exception is thrown during the call to T's copy assignment, the state of its contained value is as defined= by the exception safety guarantee of T's copy constructor.

=20 =20

optional<T>& optional<T>::operator=3D(optional<T= >&& rhs) noexcept(see below);

=20
Requires:

is_move_constructible<T>::value is true and is_move_assignable<T>::value is true.

Effects:

If init =3D=3D false &&am= p; rhs.init =3D=3D false, no effect. If init =3D=3D true && rhs.init =3D=3D false, destroys the c= ontained value by calling val->T::~T(). If init =3D=3D false && rhs.init =3D=3D true, constructs the contained value as if direct-non-list-initializing an = object of type T with std::move(*rhs).= If init =3D=3D true && rhs.init =3D=3D= true, assigns std::move(*rhs) to the contai= ned value.

Returns:

*this

Postconditions:

bool(rhs) =3D=3D bool(= *this).

Remarks:

The expression inside noexcept is= equivalent to:

is_nothrow_move_assignable<T>::value && is_n=
othrow_move_constructible<T>::value
Exception Safety:

If any exception is thrown values of = init and rhs.init remain un= changed. If an exception is thrown during the call to T's move= constructor, the state of *rhs.val is determined by exception= safety guarantee of T's move constructor. If an exception is = thrown during the call to T's move assignment, the state of *val and *rhs.val is determined by excep= tion safety guarantee of T's move assignment.

=20 =20

template <class U> optional<T>& optional<T>::= operator=3D(U&& v);

=20
Requires:

is_constructible<T, U>::value is true and is_assignable<U, T>::value = is true.

Effects:

If bool(*this) =3D=3D true assign= s std::forward<U>(v) to the contained value; = otherwise constructs the contained value as if direct-non-list-initializing= object of type T with std::forward<U>(v).

Returns:

*this

Postconditions:

bool(*this) =3D=3D true.

Exception Safety:

If any exception is thrown value of <= code>init remains unchanged. If an exception is thrown du= ring the call to T's constructor, the state of v is determined by exception safety guarantee of T's = constructor. If an exception is thrown during the call to T's = assignment, the state of *val and v is determined by exception safety guarantee of T's as= signment.

Remarks:

The function shall not participate in overload= resolution unless is_same<typename remove_reference<U>::ty= pe, T>::value is true.

[Note: The reson to provide such generic assignment and then co= nstraining it so that effectively T =3D=3D U is t= o guarantee that assignment of the form o =3D {} is unambiguou= s. —end note]

=20

template <class... Args> optional<T>& optional<T= >::emplace(Args&&... args);

=20
Requires:

is_constructible<T, Args&&..= ..>::value is true.

Effects:

Calls *this =3D nullopt. Then ini= tializes the contained value as if constructing an object of type T with the arguments std::forward<Args>(args)...= .

Returns:

*this

Postconditions:

bool(*this) =3D=3D true.

Throws:

Whatever expression T(std::forward<Arg= s>(args)...) throws.

Exception Safety:

If an exception is thrown during the = call to T's constructor, *this is disengaged, and= the previous *val (if any) has been destroyed.

=
=20 =20

template <class U, class... Args> optional<T>& opti= onal<T>::emplace(initializer_list<U> il, Args&&a= mp;... args);

=20
Requires:

is_constructible<T, initializer_list= <U>, Args&&...>::value is true.

Effects:

Calls *this =3D nullopt. Then ini= tializes the contained value as if constructing an object of type T with the arguments il, std::forward<Args>(args)....

Returns:

*this

Postconditions:

bool(*this) =3D=3D true.

Throws:

Whatever expression T(il, std:= :forward<Args>(args)...) throws.

Exception Safety:

If an exception is thrown during the = call to T's constructor, *this is disengaged, and= the previous *val (if any) has been destroyed.

=
Remarks:

The function shall not participate in overload= resolution unless is_constructible<T, initializer_list<U>, = Args&&...>::value is true.

=20
20.5.4.4 Swap [optional.object.swap]

void optional<T>::swap(optional<T>& rhs) noexcept(s= ee below);

=20
Requires:

T shall be swappable for lvalues= and is_move_constructible<T>::value is true.

Effects:

If init =3D=3D false && = rhs.init =3D=3D false, no effect. If init =3D= =3D true && rhs.init =3D=3D false, constructs the contain= ed value of rhs by direct-initialization with std::move(*(*this)), followed by val->T::~T(), swap(i= nit, rhs.init). If init =3D=3D fal= se && rhs.init =3D=3D true, constructs the contained valu= e of *this by direct-initialization with std::move(*rhs), followed by rhs.val->T::~T(), swap(init, rhs.init). If init =3D=3D true && = rhs.init =3D=3D true, calls swap(*(*this), *rh= s).

Throws:

Whatever expressions swap(declval<T&am= p;>(), declval<T&>()) and T{move(declval<T&= ;&>())} throw.

Remarks:

The expression inside noexcept is= equivalent to: 

is_nothrow_move_constructible<T>::value && noexc=
ept(swap(declval<T&>(), declval<T&>()))
Exception Safety:

If any exception is thrown values of = init and rhs.init remain un= changed. If an exception is thrown during the call to function swap the state of *val and *rhs.val i= s determined by the exception safety quarantee of swap for lva= lues of T. If an exception is thrown durning the call to T's move constructor, the state of *val and= *rhs.val is determined by the exception safety quarantee of <= code>T's move constructor.

=20 =20
20.5.4.5 Observers [optional.object.observe]

constexpr T const* optional<T>::operator->() const;
T* = optional<T>::operator->();

=20
Requires:

bool(*this) =3D=3D true.

Returns:

val

Throws:

nothing.

Remarks:

Unless T is a user-defined type w= ith overloaded unary operator&, the first function shall b= e a constexpr function.

=20 =20

constexpr T const& optional<T>::operator*() const;
T&a= mp; optional<T>::operator*();

=20
Requires:

bool(*this) =3D=3D true.

Returns:

*val

Throws:

nothing.

Remarks:

The first function shall be a constexpr<= /code> function.

=20 =20

constexpr explicit optional<T>::operator bool() noexcept;

=20
Returns:

init

Remarks:

this function shall be a constexpr function.

=20 =20

constexpr T const& optional<T>::value() const;
T& = optional<T>::value();

=20
Returns:

*val, if bool(*t= his).

Throws:

bad_optional_access if !*thi= s.

Remarks:

The first function shall be a constexpr<= /code> function.

=20 =20

template <class U> constexpr T optional<T>::value_or(U&= amp;& v) const&;

=20
Requires:

is_copy_constructible<T>::value is true and is_convertible<U&&, T>::= value is true.

Returns:

bool(*this) ? **this : static_cast<T&= gt;(std::forward<U>(v)).

Throws:

Whatever the execution of T's cons= tructor selected for the initialization of the return value throws.

Exception Safety:

If init =3D=3D true<= /code> and exception is thrown durning the call to T's constru= ctor, the value of init and v remains unchanged and the state of *val is deter= mined by the exception safety quarantee of the selected T's co= nstructor. Otherwise, when exception is thrown durning the call to T<= /code>'s constructor, the value of *this remains un= changed and the state of v is determined by the exc= eption safety quarantee of the selected T's constructor

Remarks:

If the selected T's constructor i= s a constexpr constructor, this function shall be a cons= texpr function.

=20 =20

template <class U> T optional<T>::value_or(U&& = v) &&;

=20
Requires:

is_move_constructible<T>::value is true and is_convertible<U&&, T>::= value is true.

Returns:

bool(*this) ? std::move(**this) : static= _cast<T>(std::forward<U>(v)).

Throws:

Whatever the execution of the selected T<= /code>'s constructor selected for the initialization of the return value th= rows.

Exception Safety:

If init =3D=3D true<= /code> and exception is thrown durning the call to T's constru= ctor, the value of init and v remains unchanged and the state of *val is deter= mined by the exception safety quarantee of the T's constructor= .. Otherwise, when exception is thrown durning the call to T's = constructor, the value of *this remains unchanged a= nd the state of v is determined by the exception sa= fety quarantee of the selected T's constructor

=20

20.5.5 In-place construction [optional.inplace]

struct emplace_t{};
constexpr emplace_t emplace{};

The struct emplace_t is a disengaged structure type used = as a unique type to disambiguate constructor and function overloading. Spec= ifically, optional<T> has a constructor with empla= ce_t as the first argument followed by an argument pack; this indica= tes that T should be constructed in-place (as if by a call to = placement new expression) with the forwarded argument pack as parameters.

=20

20.5.6 Disengaged state indicator [optional.nullopt]

struct nullopt_t{see below};
constexpr nullopt_t nullo= pt(unspecified);

The struct nullopt_t is an empty structure type used as a= unique type to indicate a disengaged state for optional objec= ts. In particular, optional<T> has a constructor with nullopt_t as single argument; this indicates that a disengaged o= ptional object shall be constructed.

=20

Type nullopt_t shall not have a default constructor. It s= hall be a literal type. Constant nullopt shall be initialized = with argument of literal type.

=20 =20 =20

20.5.7 Class bad_optiona= l_access [optional.bad_optional_access]=

=20 
namespace std {
  class bad_optional_access : public logic_error {
  public:
    explicit bad_optional_access(const string& what_arg);
    explicit bad_optional_access(const char* what_arg);
  };
}

The class bad_optional_access defines the type of objects t= hrown as exceptions to report the situation where an attempt is made to acc= ess the value of a disengaged optional object.

=20 bad_optional_access(const string& what_arg);

=20
Effects:

Constructs an object of class bad_optional= _access.

Postcondition:

strcmp(what(), what_arg.c_str()) =3D= =3D 0.

=20

=20 bad_optional_access(const char* what_arg);

=20
Effects:

Constructs an object of class bad_optional= _access.

Postcondition:

strcmp(what(), what_arg) =3D=3D 0.

=20

20.5.8 Relational operators [optional.relops]

=20

=20 template <class T> constexpr bool operator=3D=3D(const option= al<T>& x, const optional<T>& y);

=20
Requires:

T shall meet the requirements of <= code>EqualityComparable.

Returns:

If bool(x) !=3D bool(y), fals= e; otherwise if bool(x) =3D=3D false, true= ; otherwise *x =3D=3D *y.

Remarks:

Instantiations of this function template for whi= ch *x =3D=3D *y is a core constant expression, shall be = constexpr functions.

=20 =20

template <class T> constexpr bool operator!=3D(const optional= <T>& x, const optional<T>& y);

=20
Returns:

!(x =3D=3D y).

=20 =20

template <class T> constexpr bool operator<(const optional= <T>& x, const optional<T>& y);=20

Requires:

T shall meet the requirements of <= code>LessThanComparable.

Returns:

If (!y), false; otherw= ise, if (!x), true; otherwise *x < *y.

Remarks:

Instantiations of this function template for whi= ch *x < *y is a core constant expression, shall be co= nstexpr functions.

=20

template <class T> constexpr bool operator>(const optional= <T>& x, const optional<T>& y);=20

Returns:

(y < x).

=20 =20

=20 template <class T> constexpr bool operator<=3D(const optio= nal<T>& x, const optional<T>& y);=20

Returns:

!(y < x).

=20 =20

template <class T> constexpr bool operator>=3D(const optio= nal<T>& x, const optional<T>& y);=20

Returns:

!(x < y).

=20 =20

20.5.9 Comparison with nullopt [optional.nullops]

=20 =20

template <class T> constexpr bool operator=3D=3D(const option= al<T>& x, nullopt_t) noexcept;
template <class T= > constexpr bool operator=3D=3D(nullopt_t, const optional<T>& = x) noexcept;

=20
Returns:

(!x).

template <class T> constexpr bool operator!=3D(const optional= <T>& x, nullopt_t) noexcept;
template <class T&g= t; constexpr bool operator!=3D(nullopt_t, const optional<T>& x) n= oexcept;

=20
Returns:

bool(x).

=20

template <class T> constexpr bool operator<(const optional= <T>& x, nullopt_t) noexcept;

=20
Returns:

false.

template <class T> constexpr bool operator<(nullopt_t, con= st optional<T>& x) noexcept;

=20
Returns:

bool(x).

=20

template <class T> constexpr bool operator<=3D(const optio= nal<T>& x, nullopt_t) noexcept;

=20
Returns:

(!x).

template <class T> constexpr bool operator<=3D(nullopt_t, = const optional<T>& x) noexcept;

=20
Returns:

true.

=20 =20

template <class T> constexpr bool operator>(const optional= <T>& x, nullopt_t) noexcept;

=20
Returns:

bool(x).

template <class T> constexpr bool operator>(nullopt_t, con= st optional<T>& x) noexcept;

=20
Returns:

false.

=20

template <class T> constexpr bool operator>=3D(const optio= nal<T>& x, nullopt_t) noexcept;

=20
Returns:

true.

template <class T> constexpr bool operator>=3D(nullopt_t, = const optional<T>& x) noexcept;

=20
Returns:

(!x).

=20 =20

20.5.10 Comparison with T= [optional.comp_with_t]

template <class T> constexpr bool operator=3D=3D(const option= al<T>& x, const T& v);

=20
Returns:

bool(x) ? *x =3D=3D = v : false.

=20 =20

template <class T> constexpr bool operator=3D=3D(const T&= v, const optional<T>& x);

=20
Returns:

bool(x) ? v =3D=3D *= x : false.

=20 =20

template <class T> constexpr bool operator!=3D(const optional= <T>& x, const T& v);

=20
Returns:

bool(x) ? *x !=3D v : true.

=20 =20

template <class T> constexpr bool operator!=3D(const T& <= var>v, const optional<T>& x);

=20
Returns:

bool(x) ? v !=3D *x : true.

=20 =20

template <class T> constexpr bool operator<(const optional= <T>& x, const T& v);

=20
Returns:

bool(x) ? *x < v : true.

=20

template <class T> constexpr bool operator>(const T& <= var>v, const optional<T>& x);

=20
Returns:

bool(x) ? v > *x : true.

=20 =20

template <class T> constexpr bool operator>(const optional= <T>& x, const T& v);

=20
Returns:

bool(x) ? *x > v : false.

=20 =20

template <class T> constexpr bool operator<(const T& <= var>v, const optional<T>& x);

=20
Returns:

bool(x) ? v < *x : false.

=20 =20

template <class T> constexpr bool operator>=3D(const optio= nal<T>& x, const T& v);

=20
Returns:

bool(x) ? *x >= =3D v : false.

=20

template <class T> constexpr bool operator<=3D(const T&= ; v, const optional<T>& x);

=20
Returns:

bool(x) ? v <=3D = *x : false.

=20 =20

template <class T> constexpr bool operator<=3D(const optio= nal<T>& x, const T& v);

=20
Returns:

bool(x) ? *x <=3D= v : true.

=20 =20

template <class T> constexpr bool operator>=3D(const T&= ; v, const optional<T>& x);

=20
Returns:

bool(x) ? v >=3D = *x : true.

=20 =20

20.5.11 Specialized algorithms [optional.specalg]

template <class T> void swap(optional<T>& x, option= al<T>& y) noexcept(noexcept(x.swap(y)));

Effects:

calls x.swap(y).

=20
=20 =20

template <class T>
  constexpr optional<typename decay<T>::type> mak= e_optional(T&& v);

=20
Returns:

optional<typename decay<T>::typ= e>(std::forward<T>(v)).

=20 =20

20.5.12 Hash support [optional.hash]

template <class T> struct hash<optional<T>>;

Requires:

the template specilaization hash<T&g= t; shall meet the requirements of class template hash (= 20.9.12). The template specilaization hash<optional<T>> shall meet the requirements of class template hash.=20 For an object o of type optional<T>, = if bool(o) =3D=3D true,=20 hash<optional<T>>()(o) shall evaluate to the= same value as hash<T>()(*o).

=20
=20

Auxiliary proposal — optional references=

We propose optional references as an auxiliary proposal. This is to give= the Committee the freedom to make the decision to accept or not optional r= eferences independently of the decision to accept optional values.

Overview

Optional references are surprising to many people because they do not ap= pear to add any more functionality than pointers do. There exist though a c= ouple of arguments in favour optional references:

  • optional<T> can be used in generic code, were = T can be either a reference or an object.
  • It is slightly easier to pass arguments to functions, beacause addresso= f operator is not required.
  • Raw pointers historically add confusion in the sense that it is not cle= ar whether we should delete the value they point to or not, as well as whet= her we should expect nullptr or not. With optional references = the answer to these questions is obvious.

The interface for optional references is somewhat limited compared to th= at for optional values.

int i =3D 1;
int j =3D 2;
optional<int&> ora;                // disengaged optional ref=
erence to int
optional<int&> orb =3D i;            // contained reference r=
efers to object i

*orb =3D 3;                          // i becomes 3
ora =3D j;                           // ERROR: optional refs do not hav=
e assignment from T
ora =3D optional<int&>{j};           // contained reference r=
efers to object j
ora =3D {j};                         // same as line above
orb =3D ora;                         // rebinds orb to refers to the sa=
me object as ora
*orb =3D 7;                          // j becomes 7
ora.emplace(j);                    // OK: contained reference refers to=
 object j
ora.emplace(i);                    // OK: contained reference now refer=
s to object i
ora =3D nullopt;                     // OK: ora becomes disengaged

In some aspects optional lvalue references act like raw pointers: they a= re rebindable, may become disengaged, and do not have special powers (such = as extending the life-time of a temporary). In other aspects they act like = C++ references: they do not provide pointer arithmetic, operations like com= parisons, hashing are performed on referenced objects. 

hash<int> hi;
hash<optional<int&>> hoi;

int i =3D 0;
int j =3D 0;
optional<int&> ori =3D i;            // orj and ori refer to =
two different objects
optional<int&> orj =3D j;            // but with the same val=
ue

assert (hoi(ori) =3D=3D hi(i));       =20
assert (hoi(ori) =3D=3D hoi(orj));     // because we are hashing the va=
lues
assert (ori =3D=3D orj);               // because we are comparing the =
values

Because optional references are easily implementable with a raw pointer= , we require that almost no operation on optional references (except = value and value_or) throws exceptions.

Optional references do not popagate constness to the object they indirec= t to:

int i =3D 9;
const optional<int&> mi =3D i;
int& r =3D *mi;                      // OK: decltype(*mi) =3D=3D in=
t&
=20
optional<const int&> ci =3D i;
int& q =3D *ci;                      // ERROR: decltype(*ci) =3D=3D=
 const int&

Note also the peculiar way in which function make_optional = can create optional references:

int i =3D 1;
auto oi =3D make_optional(i);          // decltype(oi) =3D=3D optional&=
lt;int>
auto ri =3D make_optional(ref(i));     // decltype(ri) =3D=3D optional&=
lt;int&>

Practical use cases

While used significantly less often, optional references are useful in c= ertain cases. For instance, consider that you need to find a possibly missi= ng element in some sort of a collection, and if it is found, change it. The= following is a possible implementation of such function that will help wit= h the find.

optional<int&> find_biggest( vector<int>& vec )
{
  optional<int&> biggest;=20
  for (int & val : vec) {
    if (!biggest || *biggest < val) {
      biggest.emplace(val);
    }
  }
  return biggest;
}=20

This could be alternatively implemented using a raw pointer; however, op= tional reference makes it clear that the caller will not be owing the objec= t. For another example, consider that we want a function to modify the pass= ed object (storeHere in the example) as one of its responsibil= ities, but we sometimes cannot provide the object, but we do want the funct= ion to perform other responsibilities. The following is the possible implem= entation

template <typename T>
T getValue( optional<T> newVal =3D nullopt, optional<T&> st=
oreHere =3D nullopt )
{
  if (newVal) {
    cached =3D *newVal;
   =20
    if (storeHere) {
      *storeHere =3D *newVal; // LEGAL: assigning T to T
    }     =20
  }
  return cached;     =20
}

Again, this can also be implemented with pointers; however, with optiona= l references the ownership of the memory is clear. Additionally, we do not = have to use the indirection operator:

static int global =3D 0;
const int newVal =3D 2;
return getValue(newVal, global);

Assignment for optional refer= ences

The semantics of optional references' copy assignment turned out to be v= ery controversial. This is because whatever semantics for such assignment i= s chosen, it is confusing to many programmers. An optional reference can be= seen as a reference with postponed initialization. In this case, assignmen= t (to engaged optional reference) is expected to have deep copy semantics: = it should assign value to the referred object. On the other hand, an option= al reference can be seen as a pointer with different syntax. In this case t= he assignment (to engaged optional reference) should change the reference, = so that it refers to the new object. Neither of these models appears more v= alid than the other. On the other hand, the majority of people insist that = optional should be copy-assignable. We choose somewhat arbitralrily to prov= ide a rebinding semantics for std::optional. This is to follow= the practice adapted by std::reference_wrapper and boos= t::optional. In consequence, optional references are not value seman= tic types: operator=3D=3D compares something else than copy as= signment and constructor are copying. This should not be surprising, though= , for a component that is called a "reference".

The other semantics can be implemented by using the following idiom:

void assign_norebind(optional<T&>& optref, T& obj)
{
  if (optref) *optref =3D obj;
  else        optref.emplace(obj);
}

No rvalue binding for o= ptional references

Optional referencs cannot provide an essential feature of native referen= ces: extending the life-time of temporaries (rvalues). Temporaries can be b= ound to (1) rvalue references and to (2) lvalue references to const. In ord= er to avoid dangling reference problems we need to prevent either type of b= infing to optional references. In order to prevent the former, we disallow = optional rvalue references altogether. We are not aware of any practical us= e case for such entities. Since optional lvalue references to const appear = useful, we avoid the rvalue binding problem by requiring implementations to= "poison" rvalue reference constructors for optional lvalue references to c= onst. This may appear surprising as it is inconsistent with normal (non-opt= ional) reference behavior:

const int& nr =3D int{1};           // ok
optional<const int&> or =3D int{1}; // error: int&& ctor =
deleted

Wording

The wording for optional references is relative to the wording for optio= nal values form the main proposal. It assumes the wording for optional valu= es has already been applied.

In [optional.synop] add declaration of template specialization opt= ional<T&>:

20.5.2 Header <optional> synopsis [optional.synop]

namespace std {
namespace experimental {
  // 20.5.4, optional for=
 object types
  template <class T> class optional;

  // 20.5.5, optional =
for lvalue reference types
  template <class T> class optional<T&>;

  // 20.5.520.5.6, In-place construction
  struct emplace_t{};
  constexpr emplace_t emplace{};
=20

Next, in the same clause change:

=20 
// 20.5.1020.5=
..11, Comparison with T
  template <class T> constexpr bool operator=3D=3D(const optional<=
T>&, const T&);
  template <class T> constexpr bool operator=3D=3D(const optiona=
l<T&>&, const T&);
  template <class T> constexpr bool operator=3D=3D(const optiona=
l<const T&>&, const T&);
  template <class T> constexpr bool operator=3D=3D(const T&, cons=
t optional<T>&);
  template <class T> constexpr bool operator=3D=3D(const T&,=
 const optional<T&>&);
  template <class T> constexpr bool operator=3D=3D(const T&,=
 const optional<const T&>&);
  template <class T> constexpr bool operator!=3D(const optional<T&=
gt;&, const T&);
  template <class T> constexpr bool operator!=3D(const optional&=
lt;T&>&, const T&);
  template <class T> constexpr bool operator!=3D(const optional&=
lt;const T&>&, const T&);
  template <class T> constexpr bool operator!=3D(const T&, const =
optional<T>&);
  template <class T> constexpr bool operator!=3D(const T&, c=
onst optional<T&>&);
  template <class T> constexpr bool operator!=3D(const T&, c=
onst optional<const T&>&);
  template <class T> constexpr bool operator<(const optional<T&=
gt;&, const T&);
  template <class T> constexpr bool operator<(const optional&=
lt;T&>&, const T&);
  template <class T> constexpr bool operator<(const optional&=
lt;const T&>&, const T&);
  template <class T> constexpr bool operator<(const T&, const =
optional<T>&);
  template <class T> constexpr bool operator<(const T&, c=
onst optional<T&>&);
  template <class T> constexpr bool operator<(const T&, c=
onst optional<const T&>&);
  template <class T> constexpr bool operator<=3D(const optional<=
;T>&, const T&);
  template <class T> constexpr bool operator<=3D(const option=
al<T&>&, const T&);
  template <class T> constexpr bool operator<=3D(const option=
al<const T&>&, const T&);
  template <class T> constexpr bool operator<=3D(const T&, con=
st optional<T>&);
  template <class T> constexpr bool operator<=3D(const T&=
, const optional<T&>&);
  template <class T> constexpr bool operator<=3D(const T&=
, const optional<const T&>&);
  template <class T> constexpr bool operator>(const optional<T&=
gt;&, const T&);
  template <class T> constexpr bool operator>(const optional&=
lt;T&>&, const T&);
  template <class T> constexpr bool operator>(const optional&=
lt;const T&>&, const T&);
  template <class T> constexpr bool operator>(const T&, const =
optional<T>&);
  template <class T> constexpr bool operator>(const T&, c=
onst optional<T&>&);
  template <class T> constexpr bool operator>(const T&, c=
onst optional<const T&>&);
  template <class T> constexpr bool operator>=3D(const optional<=
;T>&, const T&);
  template <class T> constexpr bool operator>=3D(const option=
al<T&>&, const T&);
  template <class T> constexpr bool operator>=3D(const option=
al<const T&>&, const T&);
  template <class T> constexpr bool operator>=3D(const T&, con=
st optional<T>&);
  template <class T> constexpr bool operator>=3D(const T&=
, const optional<T&>&);
  template <class T> constexpr bool operator>=3D(const T&=
, const optional<const T&>&);
 =20
  // 20.5.1120.5.12=
, Specialized algorithms
  template <class T> void swap(optional<T>&, optional<T&=
gt;&) noexcept(see below);
  template <class T> constexpr optional<see below> mak=
e_optional(T&&);
 =20
  // 20.5.1220.5.13, Hash support 
  template <class T> struct hash;
  template <class T> struct hash<optional<T>>;
  template <class T> struct hash<optional<T&>>;<=
/ins>
=20

In the same clause, in the last sentence change:

A program that necessitates the instantiation of template optiona= l for an lvalue reference or rvalue reference type, or fo= r types emplace_t or nullopt_t, or a possibly cv-= qualified reference to types emplace_t or nullopt_t is ill-formed.

After clause 2.5.4 [optional.object] insert clause 20.5.5 [optional.lref= ] (clause [optional.inplace] becomes 20.5.6)

20.5.5 optional for lvalue refer= ence types [optional.lref]

namespace std {
namespace experimental {

  template <class T>
  class optional<T&>
  {
  public:
    typedef T& value_type;

    // 20.5.5.1, construction/destr=
uction
    constexpr optional() noexcept;
    constexpr optional(nullopt_t) noexcept;
    constexpr optional(T&) noexcept;
    constexpr optional(T&&) =3D delete;
    constexpr optional(const optional&) noexcept;
    constexpr explicit optional(emplace_t, T&) noexcept;
    constexpr explicit optional(emplace_t, T&&) =3D delete;
    ~optional() =3D default;

    // 20.5.5.2, mutation
    optional& operator=3D(nullopt_t) noexcept;
    template <class U> optional& operator=3D(U&&) noexcep=
t;
    template <class U> optional& operator=3D(U&&) noexcep=
t =3D delete;
    optional& emplace(T&) noexcept;
    optional& emplace(T&&) =3D delete;

    // 20.5.5.3, swap
    void swap(optional& rhs) noexcept;

    // 20.5.5.4, observers
    constexpr T* operator->() const;
    constexpr T& operator*() const;
    constexpr explicit operator bool() const noexcept;
    constexpr T& value() const;
    template <class U> constexpr typename decay<T>::type value_=
or(U&&) const&;

  private:
    T* ref;  // exposition only
  };

} // namespace experimental
} // namespace std

Engaged instances of optional<T> where T is of lvalue reference type, refer to objects of type std::remove_= reference<T>::type, but their life-time is not connected to th= e life-time of the referred to object. Destroying or disengageing the optio= nal object does not affect the state of the referred to object.

=20

Member ref is provided for exposition only. Im= plementations need not provide this member. If ref =3D=3D = nullptr, optional object is disengaged; otherwise ref points to a valid object.

In several places in this Clause the expression static_addressof= (v) is used. This expression is defined as follows. If ty= pe typename decay<decltype(v)>::type is a use= r-defined class type with overloaded operator->:

=20 
addressof(v)
=20

otherwise:

=20 
&(v)
=20 =20 =20 =20 =20
20.5.5.1 Construction and destruction [optional.lref.ctor]

constexpr optional<T&>::optional() noexcept;
constexpr optional<T&>::optional(nullopt_t) noexcept;

Effects:

Constructs a disengaged optional = object by initializing ref with nullptr.

Postconditions:

bool(*this) =3D=3D false.<= /p>

Remarks:

These constructors shall be constexpr constructors (7.1.5).

constexpr optional<T&>::optional(T& v) noe= xcept;

=20
Effects:

Constructs an engaged optional ob= ject by initializing ref with static_addresso= f(v).

Postconditions:

bool(*this) =3D=3D true &&= ; static_addressof(*(*this)) =3D=3D static_addressof(v).<= /p>

Remarks:

Unless T is a user-defined class = type with overloaded operator->, this constructor shall be = a constexpr constructor.

=20 =20 =20

constexpr optional<T&>::optional(const optional& rhs) noexcept;<= /code>

=20
Effects:

If rhs is disengaged, = initializes ref with nullptr; otherwis= e, constructs an engaged object by initializing ref= with static_addressof(*rhs).

Postconditions:

If bool(rhs) =3D=3D tr= ue, then bool(*this) =3D=3D true && static_addressof(*= (*this)) =3D=3D static_addressof(*rhs); otherwise b= ool(*this) =3D=3D false.

Remarks:

This constructor shall be a constexpr constructor.

=20 =20

constexpr explicit optional<T&>::optional(emplace_t, T&am= p; v) noexcept;

=20
Effects:

Constructs an engaged optional ob= ject by initializing ref with static_addresso= f(v).

Postconditions:

bool(*this) =3D=3D true &&= ; static_addressof(*(*this)) =3D=3D static_addressof(v).<= /p>

Remarks:

Unless T is a user-defined class = type with overloaded operator->, this constructor shall be = a constexpr constructor.

=20 =20 =20

optional<T&>::~optional() =3D default;

=20
Effects:

No effect. This destructor shall be a trivial = destructor.

=20 =20 =20
20.5.5.2 Mutation [optional.lref.mutate]
=20 =20

optional<T&>& optional<T&>::operator=3D(nul= lopt_t) noexcept;

Effects:

Assigns ref with a val= ue of nullptr. If ref was non-null ini= tially, the object it referred to is unaffected.

Returns:

*this.

Postconditions:

bool(*this) =3D=3D false.<= /p>

=20 =20

template <class U> optional<T&>& optional<T&= amp;>::operator=3D(U && v) noexcept;

=20
Effects:

Assigns ref with a val= ue of v.ref. If ref was non-null initially, the object it referred to is unaffected.

Returns:

*this.

Postconditions:

(!*this) ? (!v) : bool= (v) && static_addressof(*(*this)) =3D=3D static_addresso= f(*v).

Remarks:

This function shall not participate in overloa= d resolution unless is_same<typename decay<U>::type, optiona= l<T&>>::value is true.

=20 =20

template <class U> optional<T&>& optional<T&= amp;>::operator=3D(U && v) noexcept =3D delete;

=20
Remarks:

This function shall not participate in overloa= d resolution unless is_same<typename decay<U>::type, optiona= l<T&>>::value is false.

=20 =20

[Note: The reson to provide these two overloads is to enable no= tation oj =3D {} and oj =3D {j} and copy/move ass= ignment, but to prevent notation oj =3D j, where oj is of type optional<T&> and j is of = type T. —end note]

=20 =20

optional<T&>& optional<T&>::emplace(T& = v) noexcept;

Effects:

Assigns ref with a val= ue of static_addressof(v). If *this wa= s engaged before the call the object it referred to is not affected.

Returns:

*this.

Postconditions:

bool(*this) =3D=3D true &&= ; static_addressof(*(*this)) =3D=3D static_addressof(v).<= /p>

=20
20.5.5.3 Swap [optional.lref.observe]

void optional<T&>::swap(optional& rhs) noe= xcept;

=20
Effects:

Calls swap(ref, rhs.ref).

=20 =20 =20
20.5.5.4 Observers [optional.lref.observe]
=20 =20

constexpr T* optional<T&>::operator->() const;

=20
Requires:

bool(*this) =3D=3D true.

Returns:

ref.

Throws:

nothing.

=20 =20

constexpr T& optional<T&>::operator*() const;

=20
Requires:

bool(*this) =3D=3D true.

Returns:

*ref

Throws:

nothing.

=20 =20

constexpr T& optional<T&>::value() const;

=20
Returns:

*ref, if bool(*t= his) =3D=3D true.

Throws:

bad_optional_access if bool(= *this) =3D=3D false.

Remarks:

This function shall be a constexpr function.

=20

constexpr explicit optional<T&>::operator bool() noexcept= ;

=20
Returns:

ref !=3D nullptr

=20 =20

template <class U> constexpr typename decay<T>::type op= tional<T>::value_or(U&& v) const&;

=20
Requires:

is_copy_constructible<T>::value is true and is_convertible<U&&, T>::= value is true.

Returns:

bool(*this) ? **this : static_cast<ty= pename decay<T>::type>(std::forward<U>(v))= ..

Throws:

Whatever the execution of T's cons= tructor selected for the initialization of the return value throws.

Exception Safety:

If init =3D=3D true<= /code> and exception is thrown durning the call to T's constru= ctor, the value of *this and v remains= unchanged. Otherwise, when exception is thrown durning the call to T= 's constructor, the value of *this remains u= nchanged and the state of v is determined by the ex= ception safety quarantee of the selected T's constructor

Remarks:

If the selected T's constructor i= s a constexpr constructor, this function shall be a cons= texpr function.

=20

In subclause [optional.comp_with_t] change:

20.5.1020.5.11 C= omparison with T [optional.comp_wi= th_t]

template <class T> constexpr bool operator=3D=3D(const option= al<T>& x, const T& v);
template= <class T> constexpr bool operator=3D=3D(const optional<T&>= & x, const T& v);
template <= class T> constexpr bool operator=3D=3D(const optional<const T&>= ;& x, const T& v);

=20
Returns:

bool(x) ? *x =3D=3D = v : false.

=20 =20

template <class T> constexpr bool operator=3D=3D(const T&= v, const optional<T>& x);
template <class = T> constexpr bool operator=3D=3D(const T& v, const option= al<T&>& x);
template <class T>= constexpr bool operator=3D=3D(const T& v, const optional<= ;const T&>& x);

=20
Returns:

bool(x) ? v =3D=3D *= x : false.

=20 =20

template <class T> constexpr bool operator!=3D(const optional= <T>& x, const T& v);
template &= lt;class T> constexpr bool operator!=3D(const optional<T&>&= ; x, const T& v);
template <clas= s T> constexpr bool operator!=3D(const optional<const T&>&= x, const T& v);

=20
Returns:

bool(x) ? *x !=3D v : true.

=20 =20

template <class T> constexpr bool operator!=3D(const T& <= var>v, const optional<T>& x);
template <class T&= gt; constexpr bool operator!=3D(const T& v, const optional&l= t;T&>& x);
template <class T> con= stexpr bool operator!=3D(const T& v, const optional<const= T&>& x);

=20
Returns:

bool(x) ? v !=3D *x : true.

=20 =20

template <class T> constexpr bool operator<(const optional= <T>& x, const T& v);
template &= lt;class T> constexpr bool operator<(const optional<T&>&= ; x, const T& v);
template <clas= s T> constexpr bool operator<(const optional<const T&>&= x, const T& v);

=20
Returns:

bool(x) ? *x < v : true.

=20

template <class T> constexpr bool operator>(const T& <= var>v, const optional<T>& x);
template <class T&= gt; constexpr bool operator>(const T& v, const optional&l= t;T&>& x);
template <class T> con= stexpr bool operator>(const T& v, const optional<const= T&>& x);

=20
Returns:

bool(x) ? v > *x : true.

=20 =20

template <class T> constexpr bool operator>(const optional= <T>& x, const T& v);
template &= lt;class T> constexpr bool operator>(const optional<T&>&= ; x, const T& v);
template <clas= s T> constexpr bool operator>(const optional<const T&>&= x, const T& v);

=20
Returns:

bool(x) ? *x > v : false.

=20 =20

template <class T> constexpr bool operator<(const T& <= var>v, const optional<T>& x);
template <class T&= gt; constexpr bool operator<(const T& v, const optional&l= t;T&>& x);
template <class T> con= stexpr bool operator<(const T& v, const optional<const= T&>& x);

=20
Returns:

bool(x) ? v < *x : false.

=20 =20

template <class T> constexpr bool operator>=3D(const optio= nal<T>& x, const T& v);
templat= e <class T> constexpr bool operator>=3D(const optional<T&&g= t;& x, const T& v);
template &l= t;class T> constexpr bool operator>=3D(const optional<const T&= >& x, const T& v);

=20
Returns:

bool(x) ? *x >= =3D v : false.

=20

template <class T> constexpr bool operator<=3D(const T&= ; v, const optional<T>& x);
template <class= T> constexpr bool operator<=3D(const T& v, const opti= onal<T&>& x);
template <class T&g= t; constexpr bool operator<=3D(const T& v, const optional= <const T&>& x);

=20
Returns:

bool(x) ? v <=3D = *x : false.

=20 =20

template <class T> constexpr bool operator<=3D(const optio= nal<T>& x, const T& v);
templat= e <class T> constexpr bool operator<=3D(const optional<T&&g= t;& x, const T& v);
template &l= t;class T> constexpr bool operator<=3D(const optional<const T&= >& x, const T& v);

=20
Returns:

bool(x) ? *x <=3D= v : true.

=20 =20

template <class T> constexpr bool operator>=3D(const T&= ; v, const optional<T>& x);
template <class= T> constexpr bool operator>=3D(const T& v, const opti= onal<T&>& x);
template <class T&g= t; constexpr bool operator>=3D(const T& v, const optional= <const T&>& x);

=20
Returns:

bool(x) ? v >=3D = *x : true.

In clause [optional.specalg] change:

=20

template <class T>
  constexpr optional<Vtypename de= cay<T>::type> make_optional(T&& v);

=20
Returns:
=20

optional<Vtypename decay<T&= gt;::type>(std::forward<T>(v)),
w= here V is defined as X& i= f T equals reference_wrapper<X>; otherwise = V is typename decay<T>::type.

In clause [optional.hash] add:

20.5.1220.5.13 Hash sup= port [optional.hash]

template <class T> struct hash<optional<T>>;

Requires:

the template specilaization hash<T&g= t; shall meet the requirements of class template hash (= 20.9.12). The template specilaization hash<optional<T>> shall meet the requirements of class template hash.=20 For an object o of type optional<T>, = if bool(o) =3D=3D true,=20 hash<optional<T>>()(o) shall evaluate to the= same value as hash<T>()(*o).

=20
=20

template <class T> struct hash<optional<T&>= >;

Requires:

the template specilaization <= code>hash<T> shall meet the requirements of class template hash (20.9.12). The template specilaization hash<optional<T&>><= /code> shall meet the requirements of class template hash.=20 For an object o of type optional<T&>, if bool(o) =3D=3D true,=20 hash<optional<T&>>()(o) shall evaluate t= o the same value as hash<T>()(*o).

=20

Implementability

This proposal can be implemented as pure library extension, without any = compiler magic support, in C++11. An almost full rerefence implementation o= f this proposal can be found at https://github.com/akrzemi1/Optional/. Below we demonstrate how = one can implement optional's constexpr constructo= rs to engaged and disengaged state as well as constexpr = operator* for TriviallyDestructible T's. <= /p> 

namespace std {
namespace experimental {

#if defined NDEBUG
# define ASSERTED_EXPRESSION(CHECK, EXPR) (EXPR)
#else
# define ASSERTED_EXPRESSION(CHECK, EXPR) ((CHECK) ? (EXPR) : (fail(#CHECK,=
 __FILE__, __LINE__), (EXPR)))
  inline void fail(const char* expr, const char* file, unsigned line) { /*...*/ }
#endif

struct dummy_t{};

template <class T>
union optional_storage
{
  static_assert( is_trivially_destructible<T>::value, "" );

  dummy_t dummy_;
  T       value_;

  constexpr optional_storage()            // null-state ctor
    : dummy_{} {}

  constexpr optional_storage(T const& v)  // value ctor
    : value_{v} {}

  ~optional_storage() =3D default;          // trivial dtor
};


template <class T>
// requires: is_trivially_destructible<T>::value
class optional
{
  bool initialized_;
  optional_storage<T> storage_;

public:
  constexpr optional(nullopt_t) : initialized_{false}, storage_{} {}

  constexpr optional(T const& v) : initialized_{true}, storage_{v} {}

  constexpr T const& operator*()=20
  {
    return ASSERTED_EXPRESSION(bool(*this), storage_.value_);
  }
 =20
  constexpr T const& value()
  {
    return *this ? storage_.value_ : (throw bad_optional_access(""), storag=
e_.value_);
  }

  // ...
};

} // namespace experimental
} // namespace std

Acknowledgements

Many people from the Boost community, participated in the developement o= f the Boost.Optional library. Sebastian Redl suggested the usage of functio= n emplace.

Daniel Krügler provided numerous helpful suggestions, corrections a= nd comments on this paper; in particular he suggested the addition of and r= eference implementation for "perfect initialization" operations.

Tony Van Eerd offered many useful suggestions and corrections to the pro= posal.

People in discussion group "ISO C++ Standard - Future Proposals" provide= d numerous insightful suggestions: Vladimir Batov (who described and suppor= ted the perfect forwarding constructor), Nevin Liber, Ville Voutilainen, Ri= chard Smiths, Dave Abrahams, Chris Jefferson, Jeffrey Yasskin, Nikolay Ivch= enkov, Matias Capeletto, Olaf van der Spek, Vincent Jacquet, Kazutoshi Sato= da, Vicente J. Botet Escriba, Róbert Dávid, Vincent Jacquet, = Luc Danton, and many more.

Joe Gottman suggested the support for hashing some optional objects.

Nicol Bolas suggested to make operator-> conditionally <= code>constexpr based on whether T::operator& is ove= rloaded.

References

  1. John J. Barton, Lee R. Nackman, "Scientific and Engineering C++: An Int= roduction with Advanced Techniques and Examples".
  2. Fernando Cacciola, Boost.Optional library (http://www.boost.org= /doc/libs/1_49_0/libs/optional/doc/html/index.html)
  3. MSDN Library, "Nullable Types (C# Programming Guide)", (http://msdn.microsoft.co= m/en-us/library/1t3y8s4s.aspx
  4. Code Synthesis Tools, "C++ Object Persistence with ODB", (http://www.co= desynthesis.com/products/odb/doc/manual.xhtml#7.3)
  5. Jaakko Järvi, Boost Tuple Library (http://www.boost.or= g/doc/libs/1_49_0/libs/tuple/doc/tuple_users_guide.html)
  6. Alisdair Meredith, John Lakos, "noexcept Prevents Library = Validation" (N3248, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2= 011/n3248.pdf)
  7. Walter E. Brown, "A Preliminary Proposal for a Deep-Copying Smart Point= er" (N3339, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n333= 9.pdf)
  8. Andrzej Krzemieński, Optional library implementation in C++11 (https://github.com/akrzemi1= /Optional/)
=20 ------=_Part_1783_16865104.1360935848759-- .