[swift-evolution] Remove isUniquelyReferenced or isUniquelyReferencedNonObjC?

[Johan Jensen]

I thought this *was* the proposal on swift-evolution.
Or do you mean github.com/apple/swift-evolution?
Does this need a full proposal and review-cycle,
as well as a number and markdown-file on the above repository?


On Thu, Dec 10, 2015 at 9:12 PM, Dmitri Gribenko via swift-evolution <
swift-evolution at swift.org> wrote:

> 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>*/
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/973cba48/attachment.html>