[swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced
Dave Abrahams
dabrahams at apple.com
Thu Jul 21 12:09:34 CDT 2016
on Wed Jul 20 2016, Arnold <swift-evolution at swift.org> wrote:
> Sent from my iPhone
>
>> On Jul 20, 2016, at 12:47 PM, Dave Abrahams <dabrahams at 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 <atrick at apple.com> wrote:
>>>>
>>>>
>>>>> On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
>>>>>
>>>>>
>>>>> The question is are they relying on the non- at 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- at objc requirement of ManageBufferPointer and
>>>>> isUniquelyReferencedNonObjC, i.e at the language/stdlib level we
>>>>> call “native” "non- at 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- at 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
More information about the swift-evolution
mailing list