on Wed Jul 20 2016, Arnold <swift-evolution@swift.org> wrote: > Sent from my iPhone > >> On Jul 20, 2016, at 12:47 PM, Dave Abrahams <dabrah...@apple.com> wrote: >> >> >> on Wed Jul 20 2016, Arnold Schwaighofer <aschwaighofer-AT-apple.com> wrote: >> >>>> On Jul 20, 2016, at 9:54 AM, Andrew Trick <atr...@apple.com> wrote: >>>> >>>> >>>>> On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer >>>>> <aschwaigho...@apple.com> 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.
You can still do that, even without a guarantee from isKnownUniquelyReferenced. You can dynamic cast to your native storage type and see if you have it. Or you can use an enum to remember what representation you store. -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution