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.
···
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 <dabrahams@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@apple.com> wrote:
On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer <aschwaighofer@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.
--
Dave