`isUniqueReferencedNonObjC` is useful if our storage could be other a native 
Swift class or an objective-c class instance.
An example of this is Array's storage: It could either be a native Swift class 
instance or if the array was bridged from cocoa an NSArray instance. Before we 
write to the array we check that it is uniquely referenced and not an NSArray. 
If either checks fail we copy the contents to a new native Swift array.
You are correct that semantically we could compose the latter. But, in some 
situations, this code should be fast, for example the array code I mentioned: 
the overhead of two runtime calls vs one matters.

> On Jul 16, 2016, at 3:49 PM, Jaden Geller <jgel...@caltech.edu> wrote:
> 
> Some explanation of the benefit of keeping both `isUniquelyReferencedUnsafe` 
> and `isUniqueReferencedNonObjC` would be useful. I’m not entirely sure why 
> the latter is useful. If it is useful, I’m not sure why we can’t just have 
> `isUniquelyReferencedUnsafe` and `isObjC`.
> 
>> On Jul 16, 2016, at 1:21 PM, Dmitri Gribenko via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> On Sat, Jul 16, 2016 at 12:47 PM, Arnold Schwaighofer via
>> swift-evolution <swift-evolution@swift.org> wrote:
>>> ## Proposed solution
>>> 
>>> Replace `isUniquelyReferenced<T : NonObjectiveCBase>` by
>>> `isUniquelyReferencedUnsafe<T: AnyObject>` and remove the 
>>> `NonObjectiveCBase`
>>> class from the standard library.
>> 
>> Thank you for this proposal!
>> 
>> For presentation and clarity, could you show the full family of
>> `isUniquely*` functions in the design section, including those
>> functions that you are not proposing to change?  This will make it
>> easier to see what choices users will get.  It would be also great to
>> include the API of similar ManagedBuffer and ManagedBufferPointer
>> APIs, if any exist.
>> 
>> 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 <griboz...@gmail.com>*/
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to