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 for isKnownUniquelyReferenced, with clarifying doc comments
-Andy
···
On Jul 20, 2016, at 9:44 AM, Arnold Schwaighofer <aschwaighofer@apple.com> wrote:
Do we continue promise that “isKnownUniquelyReferenced” returns false for non-@objc objects in the comments?
···
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
I think the conservative answer is yes. Since there might be clients relying on the behavior.
···
On Jul 20, 2016, at 10:12 AM, Arnold Schwaighofer via swift-evolution <swift-evolution@swift.org> 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?”
IMO we should not make that promise. There's not much you can do with it.
···
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?
- 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@swift.org> wrote:
On Jul 20, 2016, at 10:12 AM, Arnold Schwaighofer via swift-evolution <swift-evolution@swift.org> 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 the conservative answer is yes. Since there might be clients relying on the behavior.
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.
I am fine with dropping the promise, though.
···
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:
Yeah, I think we’re more interested in directly supporting CoW than we are in supporting awkward bridging models.
-Andy
···
On Jul 20, 2016, at 1:00 PM, Arnold <aschwaighofer@apple.com> 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.
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.