> On 9 Nov 2016, at 10:00, ilya <[email protected]> wrote: > > > What do you imagine being inside .complicatedStuff()? It shouldn't be > > possible for it to change foo to nil, as even if .complicatedStuff() > > reassigned this, it would be doing so as type T. > > Why do you think so? All objects can be changed in any method. Let's rename > foo to pet and complicatedStuff to setFree to give a specific example: > > class Pet { > var owner: Person? > func setFree() > { > // Maintain the relationship correctness. > owner?.pet = nil > owner = nil > } > } > > class Person { > > var pet: Pet? > > func ... { > if pet != nil { > pet.setFree() // this sets pet = nil > pet.setFree() // ???? what does this do ???? > pet.setFree() > } > } > }
Ah, this comes back to the issue of class concurrency problems; the solution to this is that class references won't be narrowed, but the type-narrowing checks will still note cases that *could* have been narrowed, so that they can produce concurrency errors at runtime rather than the more generic error. I just realised I never did provide a link to the working copy of the proposal, you can view some of the updates I've made here, which includes a note on classes and concurrency: https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-type-narrowing.md Though there is still a lot to do, especially if I'm going to have to change the proposal to use a keyword instead to avoid the Optional<T> to T method shadowing problem. So yeah, in other words I'm assuming narrowing only on structs, as these are the only types where it is possible for the type-checker to be certain; though this could be extended to classes in future if we gain some attribute for indicating when they are "safe" (e.g- changed through copy-on-write, thus safe for narrowing). _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
