Re: [boost] [safe_numerics] One more review

Subject: Re: [boost] [safe_numerics] One more review
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-03-11 18:43:33

On 3/11/17 1:00 AM, Antony Polukhin via Boost wrote:

>
> Nitpicks:
>
> More generic streaming operators could be profitable (better to use
> basic_ostream<Char, Trait> instead of ostream)
> https://github.com/robertramey/safe_numerics/blob/master/include/interval.hpp#L448

I want to replace ostream with basic_stream<CharT, CharTraits> but I 
couldn't figure out the template definition syntax for using two 
separate sets of template parameters. Someone knows the answer off hand. 
  Please save me some time and post here - after you're sure it compiles.

> Many operations may be decorated with noexcept

right - I'd be curious to know what happens if one uses noexcept and 
also uses -fno_exceptions in the command line of some compileers.
>
> This macro seems broken
> https://github.com/robertramey/safe_numerics/blob/master/include/safe_literal.hpp#L142
> . Also looks like this class is not covered well with tests, because
> line https://github.com/robertramey/safe_numerics/blob/master/include/safe_literal.hpp#L90
> shall not compile
I'm going to remove it.
>
> There's a bunch of implicit conversions in the library
> https://github.com/robertramey/safe_numerics/blob/master/include/safe_base.hpp#L224
> (BTW, have not found a body of this one). Would it be better to make
> them explicit?

Ahhh - no  a very sore point.  Implicit conversions between numeric type 
are supported by the library - just as they are for builtin integer 
types.  This is to support the "drop-in" replacability goal.  The 
difference is that these conversions are checked at compile time or 
execution time.

tl;dr;
This is actually a very subtle and difficult issue brought up by 
vicente. I'm going to paraphrase.  Aren't we promoting bad practice by 
encouraging implicit conversions?  Or Isn't the way to program 
correctness paved with strong types?  I've a big promoter of this later 
view.  But I confess that making the library has led me to conclude that 
the future of correct programming needs a more nuanced view.  In order 
to promote correct code, we need to be able to express our ideas 
directly in code in a way that matches the way we use the ideas in real 
life.  In real life we say x+y with no ambiguity.  We can't express real 
numbers in computer hardware so x+y doesn't really capture what we want 
to say.  requiring explicit conversions every where is going to make it 
harder to verify that our program matches our expectation.  So (checked) 
implicit conversions are the correct approach.  It maintains our ability 
to visually compare/verify that our code matches our intention - but it 
traps the times when our expectation can't be actually realized inside 
the computer hardware.

I've become convinced that this is the way things have to be.

> Those headers are very heavy
> https://github.com/robertramey/safe_numerics/blob/7ee656ecdf23f6f29f93331769ba2209cb400be3/include/checked_result.hpp#L137-L138
> Try using <iosfwd> and making all the function below to use
> `basic_ostream<Char, Trait>&`.
right
>
> No need to define those in `namespace std`
> https://github.com/robertramey/safe_numerics/blob/7ee656ecdf23f6f29f93331769ba2209cb400be3/include/checked_result.hpp#L140
> . Defining those in `boost::numeric` namespace works fine (thanks to
> ADL!).
Hmmm - I didn't know that.
>
>
> I'd really like to see tests coverage for the library. This is pretty
> simple to add, just follow the instructions from here:
> https://svn.boost.org/trac/boost/wiki/TravisCoverals

will look into it.
>
>

Robert Ramey