> 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
