Sent from my iPhone
> On Jul 20, 2016, at 12:47 PM, Dave Abrahams <[email protected]> wrote: > > > on Wed Jul 20 2016, Arnold Schwaighofer <aschwaighofer-AT-apple.com> wrote: > >>> 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? > > I think you mean, “do we promise that “isKnownUniquelyReferenced” returns > false for @objc objects?” Yes. > > IMO we should not make that promise. There's not much you can do with it. You can implement Array (or a similar bridged) type outside of the standard library -- at least the aspect of it that transitions to a native representation when you write to it if it is non-native. I am fine with dropping the promise, though. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
