[swift-evolution] [swift-evolution-announce] [Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

[Dave Abrahams]

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?”

IMO we should not make that promise.  There's not much you can do with it.

-- 
Dave