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

Arnold Schwaighofer aschwaighofer at apple.com
Wed Jul 20 13:00:00 CDT 2016


Version 2 of the proposal https://github.com/aschwaighofer/swift-evolution/blob/remove_nonobjectivecbase_2/proposals/0125-remove-nonobjectivecbase.md

Which proposes to:

- Remove `NonObjectiveCBase` and `isUniquelyReferenced<T: NonObjectiveCBase>(_ object: T)`.

- Rename `isUniquelyReferencedNonObjC` to `isKnownUniquelyReferenced`.

- Cleanup the `ManagedBufferPointer` API by renaming `holdsUniqueReference` to
`isUniqueReference` and removing `holdsUniqueOrPinnedReference`.


> On Jul 20, 2016, at 10:24 AM, Arnold Schwaighofer via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Jul 20, 2016, at 10:12 AM, Arnold Schwaighofer via swift-evolution <swift-evolution at swift.org> 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 the conservative answer is yes. Since there might be clients relying on the behavior.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list