[Review] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

Just wanted to write the same comment as Tony: remove `NonObjC` from the
name. If possible, we should also make this work for ObjC classes.

···

2016-07-20 18:55 GMT+03:00 Tony Parker via swift-evolution < swift-evolution@swift.org>:

For what it’s worth, I agree with Dmitri on the naming of this function. I
think we should find a way to give it a name without “NonObjC” in it.

- Tony

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:

Since we’re renaming this API, it’s a good time to drop the guarantee that it will return false for NonObjC.

-Andy

···

On Jul 20, 2016, at 12:44 PM, Dave Abrahams <dabrahams@apple.com> wrote:

“isKnownUniquelyReferenced” would be fine with a warning in the doc
comment that it may always return false for objc objects.

That's a better name.

P.S. It's conceivable that someday we could correctly detect uniqueness
in (a subset of) ObjC types.

`isUniquelyReferencedNative`?

···

On Wed, Jul 20, 2016 at 10:57 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote:

Just wanted to write the same comment as Tony: remove `NonObjC` from the
name. If possible, we should also make this work for ObjC classes.

2016-07-20 18:55 GMT+03:00 Tony Parker via swift-evolution <
swift-evolution@swift.org>:

For what it’s worth, I agree with Dmitri on the naming of this function.
I think we should find a way to give it a name without “NonObjC” in it.

- Tony

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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?

--
Dave

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@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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

I am fine with dropping the promise, though.

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