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

Andrew Trick atrick at apple.com
Wed Jul 20 11:54:02 CDT 2016

> 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 for isKnownUniquelyReferenced, with clarifying doc comments

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160720/5b515053/attachment.html>

More information about the swift-evolution mailing list