(... or finer grained specification of noexcept)

A thought:
  I thought of a way to control compile-time check for noexcept with new
  language constructs like labels in function:

    void some_class::strong_op()
    {
      some_class transitive(*this);
      transitive.op1_may_throw();
      transitive.op2_may_throw();
    static noexcept:
      *this = std::move(transitive);
    }

  The "static noexcept:" enables compile-time (hence static) check for
  noexcept in all operations used below to the end of enclosing block.
  (I'm not sure what is the best syntax.)

  In this specific case, checked conditions will be equivalent with
  std::nothrow_move_assign<> and std::nothrow_destructible<> for this
  class.

Motivation:
  Some functions or commit sequences shouldn't throw an exception by
  design. Violations of this requirement is bad, but can easily happen
  in coding phase.

  Now we have a few ways to detect such violations: review the code
  by experts and test failure cases as many as possible. They are not
  easy, and require high costs.

  However, all C++11 (or later) compilers support noexcept operator
  which tells if a given expression can throw or not. We want ways to
  use this ability to detect the no-throw violation.

  "static_assert(noexcept(expr))" is a way and may help. But it is hard
  to maintain in sync with the real code including variable
  initialization and destruction. Compilers can know precisely which
  expressions (function calls) should be tested.

  Compiler can (but not required to) generate diagnostics for apparent
  noexcept violation for a function. But (as shown as the top of this
  article), partial no-throw requirements are also common to establish
  strong guarantee.

More thought:
  Besides the compile-time check, switching between noexcept(true/false)
  in a function may help compiler optimization just like noexcept does
  for function granularity. "inline noexcept(bool-expr):" is my first
  thought of its syntax. This may also be used to temporarily disable
  the compile-time check for a specific part under "static noexcept:".
  (I'm not sure what is the best syntax.)

Known problems:
  Is this worth thinking more?

  How to apply that for constructor-initializer-list?
  What if ...
    C() :
      static noexcept,
      Base{},
      inline noexcept(false),
      member{}
    {
    }
  ... ?
  Mixing these with miss-ordered initializer list can be ill-formed?

  What is the best syntax? For programmer and compiler implementation.

References:
  There is an excellent article about the history and some possible
  improvements about noexcept.
  http://akrzemi1.wordpress.com/2011/06/10/using-noexcept/
  > The areas of improvement will likely include:
  >
  > 1. Static checking of no-throw guarantee, with an improved tool for
  >    locally disabling the check.

  Exception-Safe Coding (Jon Kalb)
  http://exceptionsafecode.com/slides/esc.pdf
  > The Critical Line
  > - Implementing the Strong Guarantee
  > - Deferring the commit until success is guaranteed
  This proposal would materialize "the critical line" in our source
  codes instead of just in brains.

  Many C++ programmer, including me, likely expected that the addition
  of the keyword "noexcept" would enable some compile time check for
  no-throw guarantee, and got disappointed knowing that are not true.

http://stackoverflow.com/questions/2762078/why-is-c0xs-noexcept-checked-dynamically

http://stackoverflow.com/questions/14593333/why-noexcept-is-not-enforced-at-compile-time

--
k_satoda

--

---
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 email 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-proposals/.

.