Re: [boost] a safe integer library

On 1/13/16 6:58 AM, Brook Milligan wrote:

...

On Jan 12, 2016, at 10:36 PM, Robert Ramey wrote:

Within the design intention of the library of the library one would simply

safe_... x; int y

try{ y = x; // or x = y; } catch(cont std::exception e &){ // cast failed … }

Is there some reason that this use case--inquiring about the potential safety of a value—should not be an inherent element of the design? Is it not a valid use case to have a value in a wide type for which one needs to know whether it can be converted to a particular safe type? Is this not required for some aspects of interoperability with “non-safe” types?

I am left wondering why something as basic as this is so controversial, especially given that

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. But this opens up a huge amount of new territory. I have to limit the scope in order to actually deliver something. So it's safe integer. So to me, your question would be - why aren't these "libraries" exposed to the end user. The short answer is: it's a lot of work to make a library useful to an end user. One needs: a) correctly factored code b) correctly documented code c) tutorial examples and use cases. - which requires going back to a) Which doesn't sound all that bad. But the problem is that by the time you get c) done, you can't help but discover that a) and b) need to be updated - which turns out to be a lot more time consuming than first meets the eye. 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. As an aside there has been work on similar to parts of the library a) Interval library. 1) Boost Interval Library. Speaking from memory, this has more emphasis on floating point issues such as rounding and such. I don't remember if it placed so much emphasis on operator overloading to make it easily plug in compatible. I don't think it specifically addressed integer problems such as converting between integer types, overflows and the like. Didn't work at compile time. 2) Bruno Laland (?) had a compile time interval library. It was undocumented and didn't handle the corner cases of overflow etc. So this argued for making Interval as a library. b) checked operations. This is sort of no brainer. It almost has to be way it is. There are lots of libraries like this. But I couldn't find one which which was factored right, supported constexpr and had compile time handling to avoid unnecessary operations. For wider use, this would have to be modified to define the template types for other than integers. This could turn out to be stickier than meets the eye. c) checked_result. This seems obvious in retrospect - but it wasn't until I spend significant time iterating the loop above. This is basically boost optional with more than one failure condition. In my recollection there was a huge discussion about such a component as part of the review for AFIO. I never understood what the big deal was. But whenever the term "monad" gets injected into the discussion, things tend to start circling the drain. It was certainly tricky. I wanted to use Boost variant (or some other variant) but these are not literal types so can't be used with constexpr. And there is the problem of implicit conversions which I had a lot of difficulty getting correct - assuming they are even now. So there you have it. Three libraries which are mostly implemented and documented - missing examples and use cases. If you want to make a name for yourself, you could split out any of these and propose it as boost library - or just use it as is, or make the extra documentation and tests and I'll consider adding it to the safe integer library. there seem to be no runtime costs in exactly the same set of cases for which the above code has no runtime costs. Why sacrifice code clarity by not supporting this? I don't think I'm sacrificing code clarity. I hope the above gives some insight. Robert Ramey