Hello! I am asking for some feedback if my library idea is good enough to be part of boost if it will meet the requirements. When i started this small utility lib i had 3 goals in my mind: - Write cleaner interfaces - Be safer with pre and post conditions - Eliminate redundant checks whenever possible at compile time The goal is to solve this problem for primitive types. *Example "bad" code:* void set_red_color(int red) { //Why the precondition is not visible on the interface? assert(red >= 0 && red <= 255); } *Example "good" code:* void set_red_color(bounded_i<0, 255> red) {} *Example "bad" code:* void foo(int bar) { assert(bar >= 0); } *Example "good" code:* void foo(positive_i bar) {} or void foo(lower_bounded_i<0> bar) {} Basically the main idea is to have an invariant_host class, which is customizable via policies: -* Invariant policy:* Define a static check() function which ensure the invariant. - *Fail policy: *Define a static trigger_assert function which is called when the invariant policy::check is failed. If the fail policy is disabled (constexpr bool flag), then the checks doesn't happen. Defining your own class looks like this: template<typename PrimitiveType> using my_type = invariant_host<PrimitiveType, default_fail, my_invariant<PrimitiveType>>; *Optimizations:* bounded_i<0, 50> bi (30); //trigger check bounded_i<0, 100> bi2(bi); //range check happens at compile time bounded_i<51, 52> bi3(bi1); //should be compile error bounded_i<0, 50> bi4(integral_constant<int, 10>); //check should happen compile time Things like operator+,-,*,/, bitwise operators etc can trigger checks. Tho alot of times it can be optimized away. For example adding 2 positive number should stay positive. C++20(?) contracts will be great, it will allow us to write cleaner interfaces, but i don't feel like it solve every issue i would like to solve. Do you think it would be a good addition to boost? I appreciate any feedback! Thank you very much! Attila Szenczi