Workaround: use if let or guard let to guard your use of the C string array.

Comment by Matt Deckard (JIRA)

@belkadan, this bug doesn't involve optionals at all so I'm not sure how if let or guard let are workarounds. In fact, just a simple let cstr = newValue.cString(using: .utf8) appears to work around the issue.

Comment by Matt Deckard (JIRA)

Including a snippet from the attached project for illustration

    public func setStringFieldUnsafely(_ newValue: String) {
        // For some reason this will sometimes dealloc before the C function is done with it
        // Probably a compiler bug?
        Wrapped_setStringField(wrapped, newValue.cString(using: .utf8))
    }
    
    public func setStringFieldSafely(_ newValue: String) {
        // For some reason this works, while the above method does not
        let cstr = newValue.cString(using: .utf8)
        Wrapped_setStringField(wrapped, cstr)
    }

cString(using:) produces an optional Array of CChar, in case it can't convert the string to the encoding you picked.

Comment by Matt Deckard (JIRA)

@belkadan, but just extracting the result into a local variable is enough to workaround the issue, even if that variable is still an optional type. The example above already illustrates this but even if you make it the type explicitly optional the bug still does not occur:

    public func setStringFieldSafely(_ newValue: String) {
        // For some reason this works, while the above method does not
        let cstr : [CChar]? = newValue.cString(using: .utf8)
        Wrapped_setStringField(wrapped, cstr)
    }

I suspect we just don't optimize the destruction of named variables quite as much as we do temporaries. Or maybe it will reoccur with optimizations on, but not when they're off.