[swift-evolution] Remove isUniquelyReferenced or isUniquelyReferencedNonObjC?

[Andrew Trick]

> On Dec 10, 2015, at 8:59 AM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Dec 10, 2015, at 8:56 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Dec 10, 2015, at 8:50 AM, Chris Eidhof via swift-evolution <swift-evolution at swift.org> 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.

Andy