From: miles@gnu.org   
      
   DeMarcus  writes:   
   > Somehow I thought that the compiler would see that it's actually f()   
   > that is used (which is constexpr) and that it uses a const int which   
   > must have been initialized by the time it's used in f(). Therefore the   
   > compiler could ignore that the constructor is non-constexpr. But I'm not   
   > familiar with constexpr and I guess it's more complicated than that.   
      
   Maybe the compiler could figure it out -- but one can imagine slowly   
   increasing the complexity of the code until you get something the   
   compiler _can't_ figure out (even if, with enough though, it could be   
   proven that it's constant).  In that case maybe you'd get code some   
   compilers would accept as a compile-time constant, but others   
   wouldn't!  Such a design would be equally confusing for human readers.   
      
   Note that unlike optimization, where it's acceptable (if not   
   desirable) for a compiler to simply not optimize something it can't   
   understand.  Whether something is a compile-time constant or not,   
   however, can affect the correctness of the program; it's _not_ OK for   
   a compiler to just punt.   
      
   So the constexpr design makes things very mechanical and clear,   
   requiring no crazy smarts from the compiler, and leaving no room for   
   fuzziness.   
      
   -Miles   
      
   --   
   Opposition, n. In politics the party that prevents the Goverment from running   
   amok by hamstringing it.   
      
      
         [ 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)