On 10 Dec 2015, at 12:38, Andrew Trick <firstname.lastname@example.org> wrote:
On Dec 10, 2015, at 8:59 AM, Joe Groff <email@example.com> wrote:
On Dec 10, 2015, at 8:56 AM, Joe Groff via swift-evolution < >> firstname.lastname@example.org> wrote:
On Dec 10, 2015, at 8:50 AM, Chris Eidhof via swift-evolution < >> email@example.com> wrote:
There are two functions isUniquelyReferencedNonObjC and
isUniquelyReferenced, which do exactly the same thing. One has a more
constrained type, only accepting Swift objects. The other one accepts ObjC
objects as well, but always returns false. Regardless of whether it should
(could?) work for ObjC objects, I think this duplication is confusing (it
has confused me for a long time, and I’m happy that I can now see they’re
implemented in exactly the same way).
I think probably accepting just Swift objects would be the right thing to
do, as the function is useless for ObjC objects.
+1, I think this is just legacy we haven't gotten around to cleaning up.
cc'ing Andy, who can confirm whether the distinction is still necessary.
Yes! The most efficient runtime call is already inferred from the object
type. So there is no efficiency advantage in using one entry point over the
other. I think I left both in place because they were already public API.
But I think the “NonObjC” entry point should be removed and documented
wherever we document API changes. Maybe CHANGLELOG.md.
Side note: internally we have a Builtin.isUnique_native that force casts
Any object to Builtin.NativeObject in order to bypass the ObjC check for
unknown types. It’s only useful for ObjC bridged types and we do not expose
this through a public API.
I can have a stab at this next week, when I’m back at my regular
computer. Unless someone else feels like doing it before that, which is
fine too =).