> On Jul 20, 2016, at 9:54 AM, Andrew Trick <[email protected]> wrote: > > >> On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer <[email protected]> >> wrote: >> >> >> 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. > > The conservative thing to do is not make that promise for now and address > need later if it’s important. Conservative makes sense to me given the > current level of confusion.
>>> >>> 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 totally agree, but people can’t have it both ways. You can’t avoid a > negative in the name and refuse to define the positive nomenclature. > >> I understand the desire to remove Objc’ness from API names that can be used >> on platforms without ObjC. > > Me too. > > +1 forisKnownUniquelyReferenced, with clarifying doc comments Do we continue promise that “isKnownUniquelyReferenced” returns false for non-@objc objects in the comments? _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
