23.4 Discoverability Failure
Although the limit of a Fibonacci sequence for a given unsigned integral type is predictable and constant, requiring users of a type to know this either a priori or a posteriori is a bit rich, to say the least. Quite simply, people would not use such a component.
Our three current candidate implementations present unappealing alternatives.
- Define the sequence without end(). This precludes any use of (begin(), end()) arguments to algorithms, but it does not preclude two iterators derived from begin() being used with algorithms. Further, there's nothing stopping users from gaily advancing their begin()-derived iterator past the point of overflow, and nothing to guide them in avoiding this.
- Define the sequence with end() and rely on users' common sense not to use end() for anything at all. If they go into overflow, their program will die in a contract violation.
- Throw an exception when overflow occurs. Despite this giving a tepid feeling of robustness, it's just as much a discoverability transgression as the other two options, and it also encourages a style of programming that is rightly confined to the world of virtual machines and seven-figure installation and deployment consultancy contracts.
So, either the Fibonacci sequence is not something we should attempt to play with in an STL kind of way, or we need to apply some "finity" to it.