From: demarcus_at_hotmail_com@tellus.orb.dotsrc.org   
      
   >> The emptyset would not belong only to std::optional but could be   
   >> used by any kind of component that needs to express a missing   
   >> value. Along with emptyset I propose a new operator that   
   >> returns false if a variable is the emptyset.   
   >   
   > The problem that the implicit conversion to bool tries to solve,   
   > is mixing variable declarations with tests. If we were writing:   
   >   
   >      Type t;   
   >      if (t)   
   >          use(t);   
   >   
   > we could easily write it more explicitly as:   
   >   
   >      Type t;   
   >      if (t.is_empty_set())   
   >          use(t);   
   >   
   > We can even write:   
   >      if ((t = get_t()).is_empty_set())   
   >          use(t);   
   >   
   > However, if we want to put the declaration in the condition:   
   >   
   >      if (Type t = get_t())   
   >          use(t);   
   >   
   > then we have to rely on an implicit conversion to bool because there   
   > is (currently) no way to introduce the explicit check. None of your   
   > examples address this. If we could write something like:   
   >   
   >      if (E{Type t = get_t()})   
   >          use(t);   
   >   
   > then we could equally write:   
   >   
   >      if ((Type t = get_t()).is_empty_set())   
   >          use(t);   
   >   
   > or even:   
   >   
   >      if (std::is_empty_set(Type t = get_t()))   
   >          use(t);   
   >   
   > and there's no need for a new operator. An operator would make this   
   > more concise, but doesn't address the real issues.   
   >   
   > I imagine allowing conditions like that would be a big language   
   > change. I wouldn't be surprised if it led to parse ambiguities that   
   > confused the compiler. Burying variable declarations like that is   
   > also liable to confuse human readers.   
   >   
      
   I agree with you, that's heading towards more mess and I don't have a   
   good solution. One could argue that 'if' and 'for' are special cases   
   allowing type declarations, hence they could as well support   
      
   if( { Type t = get_t() } )   
        use(t);   
      
   and   
      
   for( { auto& t } : get_t_vec() )   
        use(t);   
      
   But as you say; it's likely to beg for compiler trouble.   
      
      
   I just see that missing values is something we work with on a daily   
   basis and so far we try solve it with everything from -1 to implicit   
   bool conversions. I mean that if we are going to support missing values   
   with value semantics in the standard, we should support it with a clear   
   unambiguous strategy where also the bool type and pointers can benefit   
   from it.   
      
   What will happen with the pointer here for instance?   
      
   optional mtp = getMyType();   
      
   if( mtp && mtp->getStatus() )   
   {   
        // ...   
   }   
      
   With support for missing values we could use the same deep search   
   mechanics as when operator-> is called (§13.3.1.2/8), like this:   
      
   if( {mtp} && mtp->getStatus() )   
   {   
        // ...   
   }   
      
      
   Regards,   
   Daniel   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)