Re: [boost] a safe integer library

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 … }

Fair enough. However, my understanding of best practice is that using exceptions for non exceptional behavior, e.g., branching on a condition, is an indication of incomplete design and runs counter to the goal of making code clear and expressive, something this library strives to do and otherwise achieves very well in my opinion. 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 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? Cheers, Brook