Re: [boost] a safe integer library

On Jan 13, 2016, at 10:07 AM, Robert Ramey wrote:

As you've noticed, the functionality you're referring to has to be part of such a library implementation. In the course of making the library, I decided that this functionality was interesting in it's own right and important for future evolution of the library (safe_money anyone?). So I documented these implementation features - checked_result, checked and interval. And each of these "sub-libraries" has it's own set of tests and documentation pages. Maybe they should be three separate libraries.

[ snip ]

If I were to continue on this, I'd make the example/use case for extending the library beyond integers to user-defined integer like types such as "money". But that would feed back to ... - I'm not sure. But surely this would be a lot more work. And I've worked on this waaaaay past my original intention. Then there is the question of demand for such a thing. The demand and interest for such a library such as safe integer is much, much much less than I anticipated. So I'm not very excited on spending more time on it.

Perhaps this (perceived lack of interest) is the fundamental issue. I have been following the discussion on your safe numerics with much interest, because for my applications (scientific computing) we need much _better_ support for this sort of thing, not less; the status quo is definitely not suitable. I continually run up against the challenge of wanting numeric types that I can just use with confidence that they perform reasonably from a mathematical point of view. Your library does exactly this for integers, with the tiny exception that it is awkward to query the validity of a value with respect to whether it matches the constraints of a narrower type. To my mind, the whole concept of a safe numeric library is essential, so I am sorry that you perceive little interest. I realize your focus to date has been on native integers, so the following clearly represents an extension to your intent for the current implementation, but not to your motivation. I will mention it, because I feel it indicates that your library already has almost everything needed and that very little extra would be needed for generality. I say this being fully aware of the iteration loop that you have been involved with and have described earlier. In the course of this discussion I have looked through the code quite a bit and it seems that there is relatively little that limits your library to integers. Here is where I see the dependence on integer types: - Reliance on std::numeric_limits for the bounds. A trivial change to numeric/convertible/bounds.hpp from the Numeric.Conversion library will make it constexpr-capable and allow a completely generic definition of bounds. Doing this requires addition of one file for the time being (the constexpr equivalent of bounds.hpp which needlessly isn’t as far as I know; maybe that has been fixed by now?) and switching the references to std::numeric_limits<T>.min() and std::numeric_limits<T>::max() to bounds<T>::lowest() and bounds<T>::highest(). The bounds<T> class can be specialized for any type, so even user-defined types will work here with the right specializations and the specializations for native types are trivial in terms of std::numeric_limits. Except for the appropriate namespace for specializations, this is an implementation detail for your library and so should affect nothing visible externally, including documentation; I’ll send you the bounds code if you like. - Reliance on non-type template parameters for things like safe_int. Those, however, are implemented in terms of the underlying basic_… types, which presumably are not obliged to use non-type template parameters; integral_constants for example would seem to work fine for every case you are actually using. Again, that is an implementation detail as far as I can tell. From there, a clear definition of the appropriate concept for types specifying the bounds can be defined so that this is a customization point for other types. This opens the way for a generic safe_numeric type, but has no impact on the utility of your current safe_int types. - Ignoring issues like denormalization. Clearly this is irrelevant for integral types, but not for floating point. Likewise, a full set of policies for floating point would need to be richer. However, I feel that a significant collection of use cases are covered by just considering the range and ignoring denormalization. It would be unfortunate to block useful advances for wont of complete generic policies for floating point. Otherwise, I am not seeing (or at least remembering) anything that is really dependent on integral types. A great step forward would be to act on these observations and take your great foundation one more step so that it is much more generic. Then we will have safe numerics as they should be done, something none of the other libraries you have mentioned really accomplishes. Thanks very much for for the lengthy discussion and for working on this foundational library. I strongly share your vision that c++ needs safe numeric types and hope that your library will grow to support that need. Cheers, Brook