I cannot argue your point beyond saying I'd hate to think that your library was accepted and then six months later you realized a fundamental oversight (and I don't assert there is one). OTOH, there is no requirement for backward compatibility in Boost and if you did discover such an oversight, you could choose to break compatibility -- for a fledgling library -- for the sake of significant improvement and avoidance of having to creating BMP2.
Thank you for your wise advice. (Or maybe even three months later...)
I think we'd all like to avoid capricious breaking changes in the future. However, if someone down the road wants to introduce a number kind we haven't even thought of yet, it's sort of inevitable that some changes (or at least extensions) may be required. It's the old chicken & egg issue, and I can't tell you at what point one hatches into the other ;-)
Thanks, John.
I agree. In my opinion, we have a solid start. We will, however, definitely learn as the library gets more exposure via review and potential inclusion in Boost. We may well end up saying, yeah that was, like, obvious. We do, however, have to start sometime. There are many calculations that can be done with this thing right off-the-rack in its current state. Many developers can make use of the power of this library even if we must refactor parts of it later. Thanks again for your comments. Best regards, Chris.