[swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end
brent at architechies.com
Sun Mar 6 00:35:19 CST 2016
>> I think it will be far easier to write generic tests of any generator than it will be to write generic tests of any function that *uses* a generic generator.
>> (Although I suppose you could assist in that testing by writing a wrapper around any sequence/collection/generator which enforces all rules as strictly as possible.)
> You could always just test the behavior of the FuseGenerator wrapping it, if you really want to be able to rely on always-returning-nil behavior. But I'm not sure what tests you'd write that even hits this case, except for a test that's designed specifically to test the post-nil behavior (which we've already established isn't necessary to check for arbitrary generators if GeneratorType leaves that as implementation-defined).
The fuse generator wouldn't do what I'm talking about. What I mean is that it might be useful for testing purposes to be able to wrap a collection/sequence in a StrictCollection/StrictSequence (with corresponding StrictGenerators, StrictIndexes,etc.) which would do things like:
* Detect if you copy a generator and then use both copies
* Detect if you call next() on a generator after it returns nil
* StrictCollection only: Invalidate all indices retrieved before any mutation
* StrictSequence only: Prevent you from making a generator more than once
The idea is that, when you're writing a piece of code that's generic on any collection or sequence type, your unit tests could pass in a StrictCollection/StrictSequence-wrapped version of whatever your actual data is, and if your code doesn't crash you can be pretty sure it's not violating any of those protocols' unevenly enforced requirements.
More information about the swift-evolution