[swift-evolution] Add ability to validate collection indices

[Xiaodi Wu]

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't really feasible, but you're
proposing the former, which may be doable.

However, I have to agree with Rien that this idea sounds brittle. Moreover,
I think you're saying we'd need a workaround when indices are "scattered to
the four winds," but IMO it'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'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.

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.


On Sun, Dec 18, 2016 at 14:47 Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:




> On 18 Dec 2016, at 11:56, Rien <Rien at balancingrock.nl> wrote:


>


> I should clarify:


>


> “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.


>


> 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.


>


> Regards,


> Rien





Again I'd compare it more to non-escaping closures; most of the time they
work just fine and you don't run into any trouble, but occasionally you
want to do something that is actually non-escaping but that the compiler
can't verify, which is why we have a mechanism to work around it.





Designed properly this should be fine, as it'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're no use at all. Thing of it like a type returning a value
with the caveat "keep it where I can see it", 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're doing 😏





Anyway, my point was to just raise it as a possible solution to this that
hadn't been discussed here yet; I never really made a formal proposal for
it so if someone else would like to that'd be great, otherwise I'll try to
at some point (alongside updating some of my other unfinished proposals).


_______________________________________________


swift-evolution mailing list


swift-evolution at swift.org


https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161218/4acb9312/attachment.html>