Yes John Bottoms, I agree with your position.
Ron Wheeler, for entirely practical considerations, I require an iterator that has a fixed number of storage locations, and which performs its function in a fixed amount of time, regardless of the value being iterated. Also for practical purposes, I consider addition to be processed in one machine cycle, regardless of whether it’s a small amount longer for asynchronous designs. One add, with this caveat, consumes as much as another.
You are certainly welcome to look inside the word and postulate a long (N bit) asynchronous word being incremented from 2^N-1 to overflow, but I wouldn't choose that representation. I stand by my requirement that the function should use a (nearly) constant amount of time and space, the same time and space consumed for each iteration regardless of the type being iterated. If you want short and long carries to be considered different consumption of time, that is your right, but I don't subscribe to that representation. No insight is gained by delving that deeply inside the ALU.
For practical considerations again, there is no point in being concerned with algorithms that delve into the carry level of timing. An "iterator" in my terms has a role to play which requires it to be approximately constant in time and space.
Clearly, every person on this list could postulate yet another kind of consideration for iterators, but I have stated mine.
HTH,
-Rich