On Darwin and iOS systems it would be hard to implement a uniques check efficiently for objective c objects.
You can't rely on retainCount is what I remember. NonPointer ISA, slide tables that contain weak and actual reference counts would make it hard to make such a check efficient. This would certainly be out of scope for swift 3 We can add the API you propose later. It has different semantics to the existing API. Sent from my iPhone On Jul 20, 2016, at 6:22 AM, Brent Royal-Gordon <[email protected]> wrote: >> On Jul 20, 2016, at 5:59 AM, Arnold Schwaighofer <[email protected]> >> wrote: >> >> The reason for this combination is data structures like Array which might >> hold an objc class which is not mutable. On a mutating operation you check >> is it uniquely reference and a swift class - if the answer is yes and you >> have enough storage you store to the current instance. (You can’t store to >> an NSArray for example, you would have to check it was a NSMutableArray, etc >> …) > > It sounds to me like this is specifically tuned to the bridging the standard > library happens to do, but you could very well want the opposite behavior in > other cases. (For instance, `NSCountedSet` and `NSURLComponents` are both > always-mutable; COW structs built around them would want to examine their > refcounts.) > > Is this the design we want to publish to users of the standard library? Or > would it be better to have an `isNonObjectiveC(_:)` call and an > `isUniquelyReferenced(_:)` call, and perhaps wrap them into one call for the > standard library's internal use? > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
