[swift-evolution] Remove isUniquelyReferenced or isUniquelyReferencedNonObjC?

Dmitri Gribenko gribozavr at gmail.com
Thu Dec 10 14:12:49 CST 2015


On Thu, Dec 10, 2015 at 11:25 AM, Chris Eidhof via swift-evolution <
swift-evolution at swift.org> wrote:

> On 10 Dec 2015, at 12:38, Andrew Trick <atrick at apple.com> wrote:
>
>
> 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.
>
>
> Okay, great!
>
> 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 =).
>

Just wanted to point out that like every API change, this needs to be
proposed on swift-evolution.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/17f0c06c/attachment.html>


More information about the swift-evolution mailing list