I think this is because this initializer comes from Foundation and therefore uses autorelease in its implementation. You can work around it by wrapping your logic in a call to autoreleasepool.

@milseman, @millenomi, this kind of thing keeps hitting people. Is there anything we can do about it?

Comment by Steve Hawley (JIRA)

Thanks for the quick response. I'll look at your suggestion.

For my particular issue, I have text that is in UTF16 from memory owned by someone else and I need it in a String with memory owned by swift that goes away when ARC says it should with minimal memory allocations in between. In the lifetime of an app, there could be millions of them.

Honestly I don't see what. This is why the ObjC Command-Line Tool project template in Xcode has an @autoreleasepool { … } block in it; it makes me question whether the Swift one should, too.

If you invoke API provided by ObjC Foundation, you can get autoreleased objects; it is a non-goal to prevent that from happening, just as it is a non-goal to not have leaks in application code that doesn't set up an autorelease pool, as it is a non-goal to attempt to deallocate objects in a dying process. We document as such here: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/20000994-SW1

— When an application terminates, objects may not be sent a dealloc message. Because the process’s memory is automatically cleared on exit, it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods.

In an AppKit or UIKit application, the autorelease pool will automatically be managed by NSRunLoop and NSApplication/UIApplication working in concert.

plinth666 (JIRA User) Does the issue go away if you add an autoreleasepool { … } block around the entire thing?

Sorry, I didn't mean "avoid autoreleases showing up as leaks". I meant "avoid use of autorelease in Foundation String APIs". (That's probably only possible if we have the autorelease-pool-steal thing working in MRR code; can't remember if that landed.)

CC @Catfish-Man

The most obvious thing that comes to mind is having String(utf16CodeUnits:, count🙂 call String.decodeCString instead of NSString(characters:,length🙂

I guess that requires null termination, so we might have to add a bytes+length version for this or something. Still, in principle, this should be straightforward I think.

If you want to make a native Swift string, you use the `String(decoding:as🙂` initializer. The C string ones are for only for C strings, that is nul-terminated.

There we go, that's the one I was thinking of. Thanks Michael.

Comment by Steve Hawley (JIRA)

Thanks for the help. I've tentatively switched over to the decoding:as initializer.

In my environment, I can't (conveniently) use an autorelease pool, but yes, that does take care of the leak.

From a pragmatic standpoint, the utf16CodeUnits variant violates the principal of least astonishment in that the behavior is outwardly surprising. As a client of this API, I would expect one of two things as an outcome: the underlying representation should behave consistently with similar strings constructed in a similar manner OR the documentation should be clear that using this particular constructor demands an autorelease pool and the consequences of not doing so.

In theory, the underlying representation of the String shouldn't matter to the consumer, but in practice if the underlying representation affects the consumer, as it affected me, then it matters very much.

To be clear, I understand the challenges of working on a large codebase and appreciate that you can't always have ideal documentation or consistent behaviors. I hope I don't sound preachy or condescending - I really appreciate the attention given to this.

It's something that I'm not quite sure how to handle. On one hand, I'm glad there is an alternative that fits your needs. On the other, If you import Foundation, or any other ObjC module, then any composition of this code with other code that happens to use Foundation API or any other ObjC module's API will be incorrect if there isn't an autorelease pool in place.

Can you stop importing Foundation in your code?

  1> String.init(utf16CodeUnits:count:) 
error: repl.swift:1:1: error: type 'String' has no member 'init(utf16CodeUnits:count:)'
String.init(utf16CodeUnits:count:)
^~~~~~ ~~~~


  1> import Foundation
  2> String.init(utf16CodeUnits:count:) 
$R0: (UnsafePointer<unichar>, Int) -> String = 0x00000001001642e0 $__lldb_expr5`partial apply forwarder for (extension in Foundation):Swift.String.init(utf16CodeUnits: Swift.UnsafePointer<Swift.UInt16>, count: Swift.Int) -> Swift.String at <compiler-generated>

Comment by Steve Hawley (JIRA)

The answer to can I avoid using Foundation is 'yes' and 'no'.

I'm not at liberty to explain in detail the circumstances, but I can say that I'm writing code that writes lots and lots of swift and where that gets used depends entirely on what my clients choose to do. I can say with confidence that 90-95% of all my clients will be using the code in a context in which there will be an autorelease pool in place, but in general I can neither make nor enforce that and that's how this was turned up in the first place. I can, however, guarantee that if my customers are using anything from Foundation, there will always be an autorelease pool.

Since Strings are not part of Foundation (although bridging, foreign strings, blah blah), I have to assume that they're going to be used from not Foundation as well.

I want to challenge the answer a little. If you would prefer no dependency on Foundation, it would probably be better to isolate importing Foundation to a separate module.