[swift-evolution] Proposal: Give weak references the ability to notify reference-holders when they transition to nil

[Etan Kissling]

Hmm, just because something could be computationally expensive, it doesn't become non-deterministic.
The program itself as a unit still performs the same steps in the same order, every time.
Which is a huge advantage over GC. Still true for a world with deinit observers.


A similar argument could be brought for non-KVO property observers.

weak var someProperty: String? {
    didSet {
         // Mine some Bitcoins.
    }
}


This is possible right now, but noone does this, because convention dictates that property observers should not be computationally expensive.

The main thing that's being proposed here is that you additionally also get a notification when the property changed to nil.


The client of an API could already implement such a notification scheme in certain cases by wrapping the object returned by the API.
Then, performing the expensive operation when the outer object is deinited.
The API couldn't prevent this, unless it returns a handle instead of an object and requires passing tha thandle back to the API with every call.
This way, the API could ensure that the client has no way to know when a handle becomes invalid.


I don't think that property observers should be treated differently, just because the cause for the property change has a different reason.



Right now, the main pain point is that implementing weak collections is really hard.
(i.e. starting a timer that periodically clears the collection of zombies, or responding to low memory conditions,
 or wrapping objects, or lazily cleanup when the collection is modified etc.)

Since a collection is something generic, you cannot require all passed-in objects to opt-in to deinit observing, either.



I don't think that KVO strictly requires the dynamic opt-in. If the compiler decides for whatever reasons to use dynamic dispatch,
i.e. because a class descends from NSObject, then KVO could still work by accident even though you have not explicitly opted in.



Etan


> On 15 Dec 2015, at 19:29, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 14, 2015, at 11:54 , John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> On Dec 13, 2015, at 7:46 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>>> On Dec 13, 2015, at 6:24 PM, Michael Henson via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 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.
>>> 
>>> +1.  This is very useful for various kinds of APIs, like a weak hashtable that wants to remove the keys when/if they get deallocated.
>> 
>> Yes.  This was always part of the long-term vision for weak references.
> 
> Hm. I don't know. Allowing arbitrary callbacks during the deinit process is a little scary to me; it means that any API that vends an object publicly can no longer assume that deinitialization is cheap. I mean, deinit can already do arbitrary work, but the creator of the class has full control over what that work is (modulo their superclasses). This feels like something that a class might need to opt into, much like KVO requires opt-in in Swift with 'dynamic'.
> 
> If one of the selling points of ARC over GC is "deterministic destruction", there's value in being able to control what happens during that destruction.
> 
> Jordan
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/fe0c2a00/attachment.sig>