Sent from my iPhone

> On Jul 16, 2016, at 9:23 PM, Andrew Trick <atr...@apple.com> wrote:
> 
> 
>> On Jul 16, 2016, at 9:17 PM, Arnold <aschwaigho...@apple.com> wrote:
>> 
>> 
>> 
>> On Jul 16, 2016, at 8:45 PM, Andrew Trick <atr...@apple.com> wrote:
>> 
>>> 
>>>> On Jul 16, 2016, at 8:36 PM, Arnold <aschwaigho...@apple.com> wrote:
>>>> 
>>>> Thank you for the feedback. Answers online.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Jul 16, 2016, at 7:38 PM, Andrew Trick <atr...@apple.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Jul 16, 2016, at 6:46 PM, Arnold Schwaighofer via swift-evolution 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> 
>>>>>> Replace isUniquelyReferenced<T : NonObjectiveCBase> by 
>>>>>> isUniquelyReferencedUnsafe<T: AnyObject> and remove the 
>>>>>> NonObjectiveCBase class from the standard library.
>>>>>> 
>>>>> 
>>>>> So we’ll have:
>>>>> 
>>>>> - isUniquelyReferencedNonObjC(object): true iff object is uniquely 
>>>>> referenced and NonObjC
>>>>> 
>>>>> - isUniquelyReferencedUnsafe(object): true iff object is uniquely 
>>>>> reference, assert NonObjC
>>>>> 
>>>>> I’m going to be picky. The “Unsafe” suffix doesn’t make sense to me. If 
>>>>> you think this is an unsafe API then it should be:
>>>>> “unsafeIsUniquelyReferenced”.
>>>>> 
>>>>> But I don’t really see how it is unsafe in the usual sense. If you want 
>>>>> to convey that the programmer needs to satisfy some precondition, which 
>>>>> is not generally associated with unsafety, then it should be:
>>>>> “isUniquelyReferencedAssumingNonObjC”
>>>> 
>>>> Makes sense to me. I think it is unsafe in the sense if you don't satisfy 
>>>> the precondition the resulting behavior is undefined in modes other than 
>>>> -Onone and not checked by a precondition predicate that traps.
>>>> 
>>>>> unsafeIsUniquelyReferenced
>>>> 
>>>> I find it kind of nice to recognize a predicate by the 'is' prefix. All 
>>>> unsafe APIs start with the word unsafe though. I could not find an unsafe 
>>>> freestanding predicate.
>>>> 
>>>> [As the implementor of the underlying builtin you may remember that it is 
>>>> not actually undefined and will return a implementation defined value 
>>>> (false) for objc classes. But we might not want to guarantee this going 
>>>> forward.]
>>> 
>>> 
>>> Oh yeah. I think I only kept the two versions for fear of breaking the API. 
>>> Since you’re renaming the second one anyway, why not just delete it with a 
>>> fixit that it's renamed to isUniquelyReferencedNonObjC?
>>> 
>>> The “assuming” version of the API is extremely confusing in addition to 
>>> being useless.
>> 
>> The unsafe version would allow us to emit more efficient code (in the 
>> future) for a static unknown object type but we know it is a native type 
>> (but not which so we can't just cast it, this is public API so we can't cast 
>> to Builtin.NativeObject).
>> 
>>   var self: AnyObject // really: AnyNativeObject
>>   ...
>>   if (!unsafeIsUniquelyReferenced(&self))
>>     self = self.copy()
>>   }
>> 
>> I admit this is somewhat contrived and am happy to just nuke the API if we 
>> agree there is no value in the use case above.
> 
> There is no sense advertising this API under some new name if it hasn’t even 
> been implemented. The API can be added when it makes sense.
> 
> +1 for eliminating it.

Today you can implement something similar using NonObjectiveCBase as your base 
class:

 var self: NonObjectiveCBase
 ...
 if (isUniquelyReferenced(&self) {...}

And get the runtime performance of the native check.

If we implemented 'unsafeIsUniquelyReferenced' we would just unsafeBitCast the 
'object' argument to Builtin.NativeObject and get the same performance.

I admit that this may be far fetched but I am trying to anticipated possible 
use cases that work today.

That use case will still work after nuking the API using the 'NonObjC' variant 
albeit slightly slower.

If we need to support it with best performance we can always bring the API back 
as you said.

+1 for nuking it from me

I will change the proposal.


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

Reply via email to