<div dir="ltr">Something occurred to me while I was thinking through a response to the thread issue. The language already provides a couple of things that behave similarly:<br><br>* deinit methods<div>* property setters<br><br>I couldn't find a documented guarantee for either of them to run on a particular thread, or any explicit detail on guarantees of behavior in threaded environments.<br><br>Given that every weak reference has to be an Optional type, I ran the following test code to see if setters are called when a weak reference becomes nil:<br><br>// swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu15.10<br></div><div><div>import Glibc</div><div><br></div><div>class Beeper {</div><div> func beep() {</div><div> print("Beep")</div><div> }</div><div>}</div><div><br></div><div>class Holder {</div><div> weak var beeper: Beeper? {</div><div> willSet {</div><div> print("willSet: \(newValue)")</div><div> }</div><div> didSet {</div><div> print("didSet: \(beeper)")</div><div> }</div><div> }</div><div><br></div><div> func doExampleLogic() {</div><div> // so there was, at one time, a strong reference in this context</div><div> let beeper = Beeper()</div><div> self.beeper = beeper</div><div> }</div><div>}</div><div><br></div><div>let holder = Holder()</div><div>holder.doExampleLogic()</div><div><br></div><div>for i in 0..<15 {</div><div> print("\(i):")</div><div><br></div><div> if let heldBeeper = holder.beeper {</div><div> print("held beeper exists")</div><div> } else {</div><div> print("held beeper is nil")</div><div> }</div><div>}</div></div><div><br></div><div>Results:<br>$ swift beeper.swift<br><div>willSet: Optional(beeper.Beeper)</div><div>didSet: Optional(beeper.Beeper)</div></div><div><div>0:</div><div>held beeper exists</div><div>1:</div><div>held beeper exists</div><div>2:</div><div>held beeper exists</div><div>3:</div><div>held beeper exists</div><div>4:</div><div>held beeper exists</div><div>5:</div><div>held beeper exists</div><div>6:</div><div>held beeper exists</div><div>7:</div><div>held beeper exists</div><div>8:</div><div>held beeper exists</div><div>9:</div><div>held beeper exists</div><div>10:</div><div>held beeper exists</div><div>11:</div><div>held beeper exists</div><div>12:</div><div>held beeper exists</div><div>13:</div><div>held beeper exists</div><div>14:</div><div>held beeper exists</div><div><br>I see the exact same results if I compile with swiftc. I expected the weakened optional to set itself to nil when the strong reference went out of scope at the end of doExampleLogic(). Have I misunderstood how weakening works?<br><br>Mike</div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 1:06 PM, Greg Parker <span dir="ltr"><<a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Dec 13, 2015, at 6:24 PM, Michael Henson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
</span><span class="">> The use-case for this comes first from proposals to have a weak-reference version of collection types. Implementing a notification signal of some sort to weak reference-holders when the reference becomes nil would make implementing those more straightforward.<br>
<br>
</span>How do you want this to work in the presence of threads?<br>
<br>
One option is that the nil transition and the callbacks are performed together, synchronously and atomically with respect to some things. The problem with this scheme is that the callback is limited in what it can do. If it does the wrong thing it will deadlock. The definition of "wrong thing" depends in part on the definition of "atomically with respect to some things". For example, if the callbacks are called atomically with respect to other weak reference writes then the callback must not store to any weak references of its own.<br>
<br>
Another option is that the callbacks are performed asynchronously some time after the nil transition itself. (Java's PhantomReference offers something like this.) The problem with this scheme is that the state of the world has moved on by the time the callback is called, which can make the callback difficult to write. In particular there is no guarantee that the weak variable's storage still exists when the callback for that weak variable is executed.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Greg Parker <a href="mailto:gparker@apple.com">gparker@apple.com</a> Runtime Wrangler<br>
<br>
<br>
</font></span></blockquote></div><br></div>