[swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end
Brent Royal-Gordon
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.
--
Brent Royal-Gordon
Architechies
More information about the swift-evolution
mailing list