[swift-evolution] Proposal: Weak Native Swift Containers

Tommy van der Vorst tommy at pixelspark.nl
Thu Dec 10 17:01:06 CST 2015

Hi Riley,

Have you tried using an array of structs that in turn hold weak references to your objects? Something like this should work:

public class Weak<T: AnyObject>: NSObject {
	public private(set) weak var value: T?

	public init(_ value: T?) {
		self.value = value

let weakFoo: [Weak<Foo>] = [Weak<Foo>(foo), ...]

Comes with the overhead of one extra object instantiated per element, but perhaps this is acceptable for your use case.


> Op 10 dec. 2015, om 23:55 heeft Riley Testut via swift-evolution <swift-evolution at swift.org> het volgende geschreven:
> In multiple places in my projects, I essentially recreate the “multiple observer” pattern used by NSNotificationCenter. Originally this was implemented by simply maintaining an array of observers, and adding to/removing from it as necessary. However, this had the unintended side effect of maintaining a strong reference to the observers, which in many cases is undesirable (for the same reasons it’s common to mark delegate properties as weak).
> Now, I’m using a private NSHashTable instance, and expose the observers as public API by creating a public computed property which essentially returns an array derived from the NSHashTable like so:
> public var receivers: [GameControllerReceiverType] {
>     // self.privateReceivers.allObjects as! [GameControllerReceiverType] crashes Swift :(
>     return self.privateReceivers.allObjects.map({ $0 as! GameControllerReceiverType })
> }
> This workaround works, but is undesirable for a number of reasons. Most notably:
> • NSHashTable is not a native Swift collection, and is also not in the Foundation Swift port, so it is not portable to other systems.
> • It also has not yet been annotated with generics, so it loses the nice type safety of other Swift collections. Because of this, I have to map the objects to the appropriate type before returning the allObjects array, which runs in O(n) time instead of O(1).
> • It’s repetitive. For every type that wants to implement this pattern, they must maintain both a public computed method and a private NSHashTable instance. This gets worse when this should be part of a protocol; there’s no way to enforce that each type conforming to it has a NSHashTable, while also keeping that information private from the consumer of the API.
> I think native swift collections with support for weak references for their contents would be very useful, and in more places than just listed above. I don’t think Array could be easily extended to support it (what happens if a value is released? does everything shift down? do they keep their indices?), but Set and Dictionary (where the keys and/or values could be weak, akin to NSMapTable) would be good candidates IMO.
> Thoughts?
> _______________________________________________
> 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/20151211/8005ebeb/attachment.html>

More information about the swift-evolution mailing list