<div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Is the idea that a Collection will invalidate all indices that *may* be stale, or only ones that *definitely* refer to the wrong thing? It sounds like OP is asking for the latter, which isn&#39;t really feasible, but you&#39;re proposing the former, which may be doable.</div><div class="gmail_msg"><br></div><div class="gmail_msg">However, I have to agree with Rien that this idea sounds brittle. Moreover, I think you&#39;re saying we&#39;d need a workaround when indices are &quot;scattered to the four winds,&quot; but IMO it&#39;s precisely when indices are scattered to the four winds that index invalidation warnings might be most valuable. By contrast, in your example where indices are kept close at hand, one can see by inspection that reusing the index is troublesome. It almost sounds to me like a reasonably achievable solution would help diagnose problems in only the easiest cases where help is least needed, and that at the same time the more complex scenarios are rare enough that a more complete solution can&#39;t be justified. I also wonder if some of it would naturally be taken care of by the borrow-checking features on the horizon for Swift 4/5.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The comparison to non-escaping closures actually gives me pause. IIUC, the only way to work around the problem of a notionally escaping closure not actually being escaping is currently extremely horrible (`unsafeBitCast`) because the proposed `withoutActuallyEscaping` has turned out to be non-trivial to implement--even though it made it through the evolution process. It would be very bad if a similar engineering problem presented itself with Collection indices, especially if the practical gains for the feature in question are scant.</div></div></div></div></div><div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Sun, Dec 18, 2016 at 14:47 Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt; On 18 Dec 2016, at 11:56, Rien &lt;<a href="mailto:Rien@balancingrock.nl" class="gmail_msg" target="_blank">Rien@balancingrock.nl</a>&gt; wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt;<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt; I should clarify:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt;<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt; “works only part of the time” was meant to say that it does not cover all cases. Sometimes a warning will be given and sometimes not. When referring to time I was thinking of the programmer, not of compilation or execution time.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt;<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt; I think that “partially detectable” features increase the cognitive workload rather than decreasing it. If that is the case then I would rather do without.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt;<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt; Regards,<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">&gt; Rien<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Again I&#39;d compare it more to non-escaping closures; most of the time they work just fine and you don&#39;t run into any trouble, but occasionally you want to do something that is actually non-escaping but that the compiler can&#39;t verify, which is why we have a mechanism to work around it.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Designed properly this should be fine, as it&#39;s not as if many programmers habitually scatter their indices to the four winds; in the vast majority of cases indices need to be kept somewhere close to what they refer to, otherwise they&#39;re no use at all. Thing of it like a type returning a value with the caveat &quot;keep it where I can see it&quot;, like when I lend someone a pen; if you want to take it somewhere else you do so on the caveat that something terrible may happen to you so you best know what you&#39;re doing 😏<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">Anyway, my point was to just raise it as a possible solution to this that hadn&#39;t been discussed here yet; I never really made a formal proposal for it so if someone else would like to that&#39;d be great, otherwise I&#39;ll try to at some point (alongside updating some of my other unfinished proposals).<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"></blockquote></div></div></div></div></div></div>