> On Jul 20, 2016, at 9:09 AM, Andrew Trick <[email protected]> wrote: > > >> On Jul 20, 2016, at 6:12 AM, Arnold Schwaighofer via swift-evolution >> <[email protected]> wrote: >> >>> isUniquelyReferencedNonObjC checks that the object is a uniquely referenced >>> swift only class. It works on non-@objc classes but will return false: The >>> API will work for @objc-classes but return false. >>> >>> 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. >>> >>> expectTrue(isUniquelyReferencedNonObjc(SwiftKlazz())) >>> expectFalse(isUniquelyReferencedNonObjc(ObjcKlazz())) >>> var y = SwiftKlazz() >>> var z = [Any] >>> z.append(y) >>> z.append(y) >>> expectFalse(isUniquelyReferencedNonObjc(y) >>> >>> The simplification of this proposal just to remove the variant that had the >>> NonObjectiveCBase prerequisite. >> >> >> Your critique of the negation still holds though. >> >> So maybe we still rename it from isUniquelyReferencedNonObjC to >> isUniquelyReferencedSwiftReference? > > What’s the difference between a “SwiftReference” and AnyObject? > > The current name is the literal meaning. The intent of being literal and > awkward is to encourage users to read the comments. This isn’t something > people should be embedding in their program logic anyway. It’s very special > purpose.
The question is are they relying on the non-@objc post-condition when the API returns true? If they were to implement something like array they might. > > That said, something like “isUniquelyReferencedNativeSwift” would work > assuming that’s semantically correct (“native" Swfit objects do not inherit > from NSObject). “isKnownUniquelyReferenced” would be fine with a warning in > the doc comment that it may always return false for objc objects. Native swift objects are the ones that use native swift reference counting and don’t alias Objc class instances. That is at least how we have defined it at the SIL (Builtin.NativeObject vs Builtin.UnknownObject) level: * A ``Builtin.NativeObject`` may alias any native Swift heap object, including a Swift class instance, a box allocated by ``alloc_box``, or a thick function's closure context. It may not alias natively Objective-C class instances. I think at the language/stdlib level the “native” concept is implementation detail that is not witnessed other than with the non-@objc requirement of ManageBufferPointer and isUniquelyReferencedNonObjC, i.e at the language/stdlib level we call “native” "non-@objc”. Which IMO is more descriptive. I understand the desire to remove Objc’ness from API names that can be used on platforms without ObjC. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
