[swift-users] Autoreleasepool for Ubuntu

[Jordan Rose]

I don’t know, this isn’t really a good Swift API either. Some of the other bare pointer cases we changed to return arrays instead for this reason, like String’s version of cString(using:). https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSStringAPI.swift#L413

I am actually in favor of having a minimal shim, but I’d rather it do nothing like Joe’s case than to start allowing arbitrarily-delayed deinitialization like this.

Jordan


> On Nov 2, 2016, at 13:00, Philippe Hausler <phausler at 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.
> 
>> On Nov 2, 2016, at 12:55 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> I’m confused about this. Shouldn’t you be able to get away with using +1 convention everywhere? What needs to have arbitrary lifetime-extension in an ARC-ified language?
>> 
>> Jordan
>> 
>>> On Nov 2, 2016, at 12:23, Philippe Hausler <phausler at apple.com <mailto:phausler at apple.com>> wrote:
>>> 
>>> So there are issues we have in swift-corelibs that suffer(leak) because we don't have ARPs on Linux. It would be super nice to have a retain until scope end concept for swift core libs where autorelease would be an accessor in unmanaged that would retain the object until the arp ends scope.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Nov 2, 2016, at 10:17 AM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>> 
>>>> 
>>>>> On Nov 2, 2016, at 09:42, Joe Groff via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>>>> 
>>>>>> 
>>>>>> On Nov 1, 2016, at 6:40 PM, Bernardo Breder via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I want to create a mini http server project and execute at Ubuntu 15. The Xcode compile and access the function "autoreleasepool", but when i compile the same code at Ubuntu, this function not found
>>>>>> 
>>>>>> For example, i can compile the code above at Xcode:
>>>>>> 
>>>>>> while true {
>>>>>>    autoreleasepool {
>>>>>>    var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 1\r\n\r\na".data(using: .utf8)!
>>>>>>    }
>>>>>> }
>>>>>> 
>>>>>> But when i try to compile at Ubuntu:
>>>>>> 
>>>>>> git at breder:~$ cat main.swift     
>>>>>> import Foundation
>>>>>> 
>>>>>> while true {
>>>>>>    autoreleasepool {
>>>>>>    var test: Data = "HTTP/1.1 200 OK\r\nContent-Length: 1\r\n\r\na".data(using: .utf8)!
>>>>>>    }
>>>>>> }
>>>>>> 
>>>>>> git at breder:~$ swiftc main.swift 
>>>>>> main.swift:4:5: error: use of unresolved identifier 'autoreleasepool'
>>>>>>    autoreleasepool {
>>>>>>    ^~~~~~~~~~~~~~~
>>>>> 
>>>>> Autoreleasepools are an ObjC compatibility feature. They aren't necessary in standalone Swift.
>>>> 
>>>> But they are necessary in Swift programs on Apple platforms (that don’t use RunLoop, anyway). Philippe, what do you think? What’s the right way to write cross-platform code that doesn’t use RunLoop or dispatch_main for an implicit autorelease pool?
>>>> 
>>>> (/me remembers +[NSAutoreleasePool drain] from the ObjC-GC days)
>>>> 
>>>> Jordan
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161102/1ad15c9c/attachment.html>