> On Nov 2, 2016, at 1:08 PM, Joe Groff via swift-users <swift-users@swift.org> 
> wrote:
> 
>> On Nov 2, 2016, at 1:00 PM, Philippe Hausler <phaus...@apple.com 
>> <mailto:phaus...@apple.com>> wrote:
>> 
>> See:
>> 
>> https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561
>>  
>> <https://github.com/apple/swift-corelibs-foundation/blob/d015466450b2675037c6f1ace8e17e73050ccfb9/Foundation/NSURL.swift#L561>
>> 
>> This is far and few between of cases that it would be useful but there are a 
>> few APIs that we have not been able to express without being able to 
>> autorelease items. Most of which we have either forbidden in Linux or 
>> redesigned because they were sub-par swift experiences. However it seems 
>> reasonable to have a minimal shim to provide cross platform code 
>> compatibility even if it does next to nothing. That way trivial code as the 
>> original issue showed can easily be directly compiled on either platform 
>> without littering gnarly #ifdefs about.
> 
> In the fullness of time, the borrow model will hopefully give us a way to 
> represent those kinds of "returns inner pointer" APIs safely in Swift without 
> relying on dynamic lifetime extension, or awkward 'with { ... }' callbacks.

Not to mention using autoreleasepool to handle returns-inner-pointer isn't 
memory safe anyway. If the autorelease pool pops too soon then you end up with 
a dangling pointer that no amount of compiler analysis can detect. 


-- 
Greg Parker     gpar...@apple.com     Runtime Wrangler


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

Reply via email to