Re: [boost] [safe_numerics] review

Subject: Re: [boost] [safe_numerics] review
From: Peter Dimov (lists_at_[hidden])
Date: 2017-03-11 22:56:25

Robert Ramey wrote:

> BTW - when are we going to a comments form Peter Dimov?

I read the documentation, and here are some comments on that:

- there is an example that explains that safe<long> is not implicitly 
convertible to int, even though long is. I think that it should be, subject 
to the usual constraint that the value can be represented in an int.

- that safe_signed_range and safe_unsigned_range have a default policy of 
native seems wrong to me. The point of these classes is to represent, well, 
ranges, and arithmetic by default (if not always) should produce the 
appropriate range of the result, that is, the equivalent of 'automatic'. In 
fact, as the ranges have no template parameter for the underlying type, I'm 
not entirely sure what 'native' is supposed to do here.

- it's not clear why safe_signed_literal and safe_unsigned_literal need 
policies at all, as all the arithmetic there happens at compile time. 
There's never a need to promote or throw.

I've misplaced the announcement e-mail, is 
https://github.com/robertramey/safe_numerics/ the right place for the code? 
Because if it is, it doesn't follow the Boost convention for the include 
directory - the headers aren't in include/boost/safe_numerics but in 
include. There's also no Jamfile in the test directory, which is of minor 
importance compared to the include issue. The library just doesn't fit into 
the Boost structure in its present state.