[swift-evolution] Add ability to validate collection indices

Haravikk swift-evolution at haravikk.me
Sun Dec 18 14:47:27 CST 2016

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

More information about the swift-evolution mailing list