[swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end
Dmitri Gribenko
gribozavr at gmail.com
Thu Mar 3 03:12:44 CST 2016
On Wed, Mar 2, 2016 at 10:47 PM, Patrick Pijnappel via swift-evolution
<swift-evolution at swift.org> wrote:
> Situation
> Currently GeneratorType.next() requires callers to not call next() after it
> has returned nil once, even encouraging a preconditionFailure() if this is
> violated:
>
> /// - Requires: `next()` has not been applied to a copy of `self`
> /// since the copy was made, and no preceding call to `self.next()`
> /// has returned `nil`. Specific implementations of this protocol
> /// are encouraged to respond to violations of this requirement by
> /// calling `preconditionFailure("...")`.
I'd like to add more context to this discussion. We added this
requirement a while ago. [1] The reason for introducing it was not
an attempt to flag bugs in client code. Rather, we were not convinced
that all generators can return nil repeatedly without loss of
efficiency or extra storage burden.
[1] https://github.com/apple/swift/commit/304b4f33ae74a5abd09da485bbc435dfa2ade522
and rdar://problem/17392226
> Adds caller burden
> To avoid breaking the requirement, the caller will not uncommonly have to track extra state and branch
I would actually say the opposite -- running a non-trivial algorithm
on generators is a very uncommon thing to do. The 99% use case for
generators is implicit usage from the for-in loop. This is why
allowing generators to be as simple as possible and pushing the
requirement for extra branches into non-trivial algorithms made sense
for us when we introduced this requirement.
> Silent corner case
> Because basically all generators keep returning nil, it's not unlikely people will write their code based on the assumption it will always return nil
This is what concerns me the most about the current rules.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
More information about the swift-evolution
mailing list