<div dir="ltr">Post-nil behavior being relevant is somewhat rare either way, but a comparison:<div><br></div><div><b>Current – post-nil unspecified</b></div><div>– 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.</div><div>– Standard library currently has 3 occurrences of this being necessary.</div><div>– As all stdlib iterators do repeat nil indefinitely, many people likely assume relying on this is OK.</div><div>– 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).</div><div><b><br></b></div><div><b>Proposed – post-nil always nil</b></div><div>– 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.</div><div>– 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).</div><div>– Implementor is more likely to be aware of the API contract because a) it&#39;s the way the stdlib iterators work b) implementors are probably more likely than callers to check the API contract.</div><div>– 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&#39;t.</div><div><br></div><div>The argument that it&#39;s risky to rely on people adhering to the API contract can be made for either case:</div><div>– &quot;Writing an iterator that doesn&#39;t repeat nil is risky as the caller might not adhere to the API contract, so just make all iterators repeat nil anyway.&quot;</div><div>– &quot;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.&quot;</div><div>But protecting both sides kinda defeats the purpose of the API contract IMO.</div></div>