• Paul A. Bristow (yes with conditions)
• Steven Watanabe (yes with conditions)
• John Maddock (yes with conditions)
• Antony Polukhin (yes)
• Barrett Adair (yes)

And three without a vote:

1. index.html in root directory that redirects to doc/.
   
2. all headers in folder include/boost/numeric/.
3. Macro safe_literal: either remove it or let it follow Boost macro naming conventions:  BOOST_NUMERIC_SAFE_LITERAL().
   

• Automatic promotion policy: either just remove it, or fix it so that:
• it can see the range of safe_base in order to allow for slower increase in sizeof(),
• it is clear from documentation how the promotion mechanism works.
• in particular, what type gets selected for bit-wise operators &, |
  
• The division bug (see below) is fixed.
  

• Decide and document up front how the library addresses each of the following different situations:
• overflow upon arithmetical operation,
• unexpected promotion to unsigned when comparing signed with unsigned number,
• arithmetic operation on unsigned int with negative value versus a signed value (-1 + 1u).
• bit-wise operation on negative signed integers (unless they are removed), or that would produce one as the result.
  
• division by zero,
• operations upon default-constructed int type with indeterminate value,
• conversion from float to int, when float contains non-integral value.
• conversion from float to int, when float contains an integral value that would overflow upon native conversion
• operator% where one operand is negative (for native ints it is implementaiton-defined)
• leftshift by 32 bits (on 32-bit int)
  

• Decide and document what safe's default constructor does.

• Document upon which operations safe<> throws exceptions (or, signals arithmetic error at run-time). IOW, document in which cases safe<> never throws exceptions (signals run-time failure) because it is able to say that the operation will always succeed.

• Document what happens when you invoke an operation on two instances of safe<> with different policies.

• Resolve name conflict with interval, which already exists in namespace boost::numeric::interval. Either use a different namespace or a different name.

• Remove anonymous namespaces from the header files. Use namespace detail and inline functions instead.

• Improve test cases, so that they also check if numeric values of computations are correct (not only whether an operation throws or not).

• Use enable_if (or similar) tricks to constrain the overload resolution for your arithmetical operations, so that they only work for numeric types rather than "any type T".
  

• Fix the division bug:
    safe<signed, automatic> a {-1};
    safe<unsigned, automatic> b {2};
    auto c = a / b; // this returns 2147483647

• Either document that safe<T> only works for scalar types (rather than any T that models concept Integer<T>), or provide alternate implementation of safe_base, as described in https://github.com/robertramey/safe_numerics/issues/44

• Fix linker errors when building a program from two cpp files that include safe_numerics headers. The error is caused by non-inline full specializations of operator<<.

• Either entirely remove the support for bit-wise ops on signed types (make it a compiler error), or provide a consistent implementation that detects any UB or surprising results.

• `++i` should return by reference; `i--` should return by value.

• operation `safe<signed>{INT_MIN} + safe<unsigned>{UINT_MAX}` throws even though the mathematical result would fit in either signed or unsigned int. This is correct according to what policies describe, but is at the same time surprising, given that comparison
  `safe<signed>{INT_MIN} < safe<unsigned>{UINT_MAX}` just gives a mathematically correct answer rather than throwing an exception. Document this behavior explicitly.
• Remove underflow_error from the policies: it sends the wrong message, that som form of an underflow is checked in this library.
• Expose functions like add(), divide() in public interface, they might be useful on their own. 
• Expose the constructor with check disabled in the public interface, like `safe<int>{1, checks_sisabled{}}` this helps to locally disable the checks where the user knows that certain chain of operaitons will not overflow, and checks are redundant, but the library cannot see it.
• Issues reported with bit-shift operators
• unary operator- on unsigned type with pormotion policy `automatic` could return a signed type.
• Use BOOST_NORETURN wherever possible, e.g. in throwing policies.
• Use BOOST_LIKELY, BOOST_UNLIKELY for the policy tests.
  
• Add support for statful policies.
• Maybe drop the support for automatic type widening, to simplify the interface and the scope of the library, and let some other library handle the widening, maybe BigInt.

Regards,
Andrzej Krzemienski