[swift-evolution] [Draft] Change IteratorType post-nil guarantee

[Patrick Pijnappel]

Post-nil behavior being relevant is somewhat rare either way, but a
comparison:

*Current – post-nil unspecified*
– Responsibility of the caller, needs to be aware of the API contract and
needs to track a bool and branch when relying on post-nil.
– Standard library currently has 3 occurrences of this being necessary.
– As all stdlib iterators do repeat nil indefinitely, many people likely
assume relying on this is OK.
– Branch and state can usually not be optimized away. Though performance is
not the key concern, iterators are often used in tight loops and can affect
very commonly used algorithms (to take the stdlib example of ASCII
decoding, it would be 25% faster with the proposed guarantee).

*Proposed – post-nil always nil*
– Responsibility of implementor of custom iterator, needs to be aware of
the API contract and needs to track a bool and branch for some cases.
– The standard library currently has no occurrences of the being necessary.
If SE-0045 is excepted, it will introduce the first case (out of 30
iterators).
– Implementor is more likely to be aware of the API contract because a)
it's the way the stdlib iterators work b) implementors are probably more
likely than callers to check the API contract.
– Branch and state (for iterators that need it) can usually be optimized
away when not needed by caller (e.g. in a for in loop). Note that when
post-nil behavior is relied upon, the caller would have had to track state
and branch already if the iterator didn't.

The argument that it's risky to rely on people adhering to the API contract
can be made for either case:
– "Writing an iterator that doesn't repeat nil is risky as the caller might
not adhere to the API contract, so just make all iterators repeat nil
anyway."
– "Writing code that relies on the iterator repeating nil is risky as the
implementor might not adhere to the API contract, so just track state and
branch in that code anyway."
But protecting both sides kinda defeats the purpose of the API contract IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160319/1dd32c2d/attachment.html>