The following is paraphrased from an issue raised by Andrzej Krzemieński as a github issue. It touches upon fundamental ideas behind the library and how these ideas as the implementation of the library collided with reality.

“In the current implementation safe<T> will only work with T being a C++ scalar type. Therefore making a general type requirements that say what operations are allowed is superfluous, and confusing (because it implies that safe<> is more generic.”

When I started out, It became clear that I wanted "safe" types to look like "numeric" types. It also became clear pretty soon that there was going to be significant template meta-programming in the implementation. Normal type traits like std::is_integer are defined in the std namespace and one is discouraged from extending it. Also I needed some compile time "max" and "lowest" values. This lead me to base the design on std::numeric_limits. But std::numeric limits is inherently extensible to any "numeric" type. For example, money is a numeric type but not an intrinsic types. So it seemed that I needed to define a "numeric" concept which required that there be an implementation of std::numeric_limits for any type T - such as money in this case. When I'm doubt - I tend to think big.

For now though I'm not going to address it. For what it's worth, my preference would be to do something like:

template<typename T>
struct range {
    T m_lowest;
    T m_highest;
    // default implementation
    range(
        const & T t_min, 
        const & T t_max
    ) :
        m_lowest(std::numeric_limits<T>::lowest(t_min),
        m_highest(std::numeric_limits<T>::max(t_max)
    {}
};

Then redeclare safe_base, etc., accordingly.

Also note that for C++20, template value parameters are no longer restricted to integer primitive types but may be class types as well. This means the library maybe extended to user class types without changing the current template signatures.