Basically, yes. You may also want to have a version for forward iterators - if you're allowed to traverse the range more than once, then it is usually more efficient to traverse it once to find out the length, throw (or whatever) if the length is too big, and otherwise traverse it a second time to actually insert the elements. (This is not always more efficient - for example, if your iterators are transform_iterators, and the transformation function they are calling is expensive, it's not - but I believe several STL implementations assume it is and do it this way).
Why would you optimize the failure case?
I agree that optimizing for the success case is the better choice when evaluating the length is not O(1). Since StaticVector forces the user to choose exactly what size it will be at compile time, it can only be reasonable to assume that they will choose a size that will succeed. That would make any failure case in which the capacity is exceeded an extremely exceptional situation which should be evaluated as lazily as possible. Furthermore, if there is a significant chance that the capacity will be exceeded, it can be checked by the user before calling a function in StaticVector. This is similar to the reason why it is desirable to make an unchecked_push_back style function available. Cheers! Andrew Hundt