Thanks for the welcome of all the other enhancements, especially in the area of conversion, to make your integer library easy to use for everyone. Further, don't get discouraged as your colleagues discuss the meaning of 0, life and the universe while people who actually would use it already understand what 0 means because we have been without, 0, this library for so long. 'Feed a mouse a cookie and he will ask for a glass of milk.'
Creating integers with variable size on the stack, that is in any case something that I will not specify, but users that want to use these tricks can just override the integer_allocator.
Currently you have an integer class which takes an integer_allocator base class. Even though the spec doesn't mention this or I glossed over reading it but you probably are going to provide a heap_integer_allocator class that could be named whatever but exists as the default integer_allocator for the integer class. This way users can just start using the library right away instead creating there own allocator the first time they use this library. What I was suggesting was not a change to the integer, integer_allocator base class or the currently unnamed heap_integer_allocator! Rather the addition of a stack_integer_allocator<size_t> : public integer_allocator. The reasons for the library to provide this instead of the end user is as follows: 1) Performance, stack based allocations are faster than heap based and in some field domains one will know the upper limit on size. This generates the need for multiple people wanting to do this especially when performance matters. 2) Standardization, if you foresee that many people are going to need this functionality than your library becomes easier because you can go ahead and provide the class instead of a large unsigned integer of people having to reinvent the wheel and create the exact same class themselves. 3) Maintain ease of use as complexity increases, in just this one area this library could suffer from the opposite problem of the standard library. The standard library algorithms was all passing 2 iterators around which allows for maximum flexibility for more complicated scenarios but lacked the overrides like boost Range where you could pass the collection and the algorithm uses begin and end for the more common and simple scenarios. Integer library does the opposite which is mostly good, it provides the heap allocator for the most common and general use but as complexity increases and someone needs stack based allocator the user is left in the lurch and have to right there own, over and over again from user to user. I just believe this library would be more feature complete if it would just go ahead and provide the both implementations up front. 4) Architectural consistency, this library is designed to behave like existing integer types that can be created both on the stack and on the heap.