Declare a pointer to a property and pass it as inout param into func in Swift?

Question

I need to choose one of some properties and pass it by reference to set it inside the func. Approximate code:

var someProperty = [SomeClass]()
var someProperty2 = [SomeClass]()

func someFunc(someObject: inout [SomeClass]) {
    ...
    someObject = ... //
}

//usage code
let obj: [SomeClass]
if someCase {
    obj = self.someProperty
    ...
} else {
    obj = self.someProperty2
    ...
}
someFunc(&obj)

The problem is obj is cannot be used as inout parameter but even if I declare it as var then obj is changed but not someProperty or someProperty2.

I read that somehow I need to declare obj as UnsafeMutablePointer and there are similar questions. But I don't know how to apply them to the code above to fix only these 3 lines (without of changing the rest of code):

let obj: [SomeClass]
obj = self.someProperty
obj = self.someProperty2

How to solve this issue?

P.S. in other words I need something like let obj: inout [SomeClass] but it is not allowed by Swift

Answer 1

After discussion in comments, the question is intended to be specifically how to work with UnsafeMutablePointer to achieve the result, and less about the best way to achieve the result.

It's important that the entirety of the code from the point of acquiring the pointer to using it be scoped within withUnsafeMutablePointer. Because it comes down to selecting between two arrays, and then passing one of them via an alias to someFunc, you don't know which pointer has to be kept live, so you have to keep them both live. Otherwise your program will likely crash when Swift invalidates it.

The proper and safe way to achieve the desired effect with pointers is like this:

func pointerSolution()
{
    var sourceArray1 = [1, 2, 3, 4]
    var sourceArray2 = [5, 6]

    func someFunc(_ someArray: inout [Int]) {
        someArray.indices.forEach { someArray[$0] = 0 }
    }
    
    let someCase = true // just for the sake of compiling a concrete case

    //usage code
    withUnsafeMutablePointer(to: &sourceArray1)
    { src1 in
        withUnsafeMutablePointer(to: &sourceArray2)
        { src2 in
            // Substitute appropriate type for `Int`
            let arrayPtr: UnsafeMutablePointer<[Int]>
            if someCase {
                arrayPtr = src1
                // Some additional code that may or may not involve arrayPtr
            } else {
                arrayPtr = src2
                // Some additional code that may or may not involve arrayPtr
            }
            someFunc(&arrayPtr.pointee)
        }
    }

    print("sourceArray1 = \(sourceArray1)")
    print("sourceArray2 = \(sourceArray2)")
}

If you have to do this is in multiple places, or just want to clean up the syntactic bloat of nesting withUnsafeMutablePointer blocks, you can provide a helper function:

func withUnsafeMutablePointers<T, R>(
    to value1: inout T, 
    and value2: inout T, 
    _ body: (UnsafeMutablePointer<T>, UnsafeMutablePointer<T>) throws -> R) rethrows -> R
{
    try withUnsafeMutablePointer(to: &value1)
    { ptr1 in
        try withUnsafeMutablePointer(to: &value2)
        { ptr2 in
            try body(ptr1, ptr2)
        }
    }
}

Then where you use it, you have one level of nesting:

func pointerSolution()
{
    var sourceArray1 = [1, 2, 3, 4]
    var sourceArray2 = [5, 6]

    func someFunc(_ someArray: inout [Int]) {
        someArray.indices.forEach { someArray[$0] = 0 }
    }
    
    let someCase = true // just for the sake of compiling a concrete case

    //usage code
    withUnsafeMutablePointers(to: &sourceArray1, and: &sourceArray2)
    { src1, src2 in
        // Substitute appropriate type for `Int`
        let arrayPtr: UnsafeMutablePointer<[Int]>
        if someCase {
            arrayPtr = src1
            // Some additional code that may or may not involve arrayPtr
        } else {
            arrayPtr = src2
            // Some additional code that may or may not involve arrayPtr
        }
        someFunc(&arrayPtr.pointee)
    }

    print("sourceArray1 = \(sourceArray1)")
    print("sourceArray2 = \(sourceArray2)")
}

If you want to live dangerously, you can do this:

func dangerousPointerSolution()
{
    var sourceArray1 = [1, 2, 3, 4]
    var sourceArray2 = [5, 6]

    func someFunc(_ someArray: inout [Int]) {
        someArray.indices.forEach { someArray[$0] = 0 }
    }

    let someCase = true // just for the sake of compiling a concrete case

    //usage code
    let address: Int
    if someCase {
        address = withUnsafeMutablePointer(to: &sourceArray1) { Int(bitPattern: $0) }
        // Some additional code that may or may not involve address
    } else {
        address = withUnsafeMutablePointer(to: &sourceArray2) { Int(bitPattern: $0) }
        // Some additional code that may or may not involve address
    }
    someFunc(&(UnsafeMutablePointer<[Int]>(bitPattern: address)!).pointee)

    print("sourceArray1 = \(sourceArray1)")
    print("sourceArray2 = \(sourceArray2)")
}

Note the pointer conversion through Int. This is because when withUnsafeMutablePointer returns, it invalidates the pointer $0 internally, and if you were to just return $0, the pointer that is returned by withUnsafeMutablePointer is also invalidated. So you have to trick Swift into giving you something you can use outside of withUnsafeMutablePointer. By converting it to an Int, you're basically saving off the valid address as a numeric value. Swift can't invalidate it. Then outside of withUnsafeMutablePointer you have to convert that Int address back into a pointer, which UnsafeMutablePointer<T> has an initializer to do (after all, you can imagine an embedded system with memory mapped I/O. You'd need to read/write to a specific address to do I/O.) Any time you have to trick the compiler into letting you do something, it should be a big red flag that maybe you shouldn't be doing that. You may still have good reasons, but at the very least, it should cause you to question them, and consider alternatives.

It's important that you don't use address to reconstruct another pointer outside of this scope. In this specific example, it remains a valid address within the function scope only because it's an address for local values that are referred to after the pointer is used. When those values go out of scope, using any pointer to them becomes a problem. If they were properties of a class letting the address escape outside of the scope of the class would be a problem when the instance is deinitialized. For a struct the problem happens sooner since it's likely it would end up being used on a copy of the struct rather than on the original instance.

In short, when using pointers, keep them as local as possible, and be sure they, or anything that can be used to reconstruct them without the original Swift "object" they point to, don't escape outside the context in which you know for sure that they are valid. This isn't C. You don't have as much control over the lifetime of allocated memory. Normally in Swift you don't have to worry about it, but when you do use pointers, it's actually harder to reason about their validity than it is in C for the very reason that you don't get to specify when allocated memory becomes invalid. For example, in Swift, it's not guaranteed that a locally allocated instance of a class will remain "live" through the end of the scope. In fact, it's often deinitialized immediately after its last use, even though there may be more code after in the same scope. If you have a pointer to such an object, even when you are still the same scope, you may now be pointing to deinitialized memory. Swift even has to provide withExtendedLifetime to deal with such cases. That's why Swift tries to limit their use solely within the withUnsafePointer family of functions. That's the only context that it can guarantee their validity. There are other contexts in which they would be valid, but the compiler can't prove that they are.

Answer 2

Apparently I was originally being dim in my reading of the question, so with an updated (and hopefully accurate) understanding, I'll re-express the question by giving concrete (and compilable) code of what I think OP wants to do, then give my solution.

I've renamed a few things to be more concrete and express their roles in the code. Given code like this:

var sourceArray1 = [1, 2, 3, 4]
var sourceArray2 = [5, 6, 7, 8]

func someFunc(_ someArray: inout [Int]) {
    someArray.indices.forEach { someArray[$0] = 0 }
}

let someCase = true // just for the sake of compiling a concrete case

//usage code
var arrayProxy: [Int]
if someCase {
    arrayProxy = sourceArray1
    // Some additional code that may or may not involve arrayProxy
} else {
    arrayProxy = sourceArray2
    // Some additional code that may or may not involve arrayProxy
}
someFunc(&arrayProxy)

print("sourceArray1 = \(sourceArray1)")
print("sourceArray2 = \(sourceArray2)")

the actual output is

sourceArray1 = [1, 2, 3, 4]
sourceArray2 = [5, 6, 7, 8]

But the desired output is

sourceArray1 = [0, 0, 0, 0]
sourceArray2 = [5, 6, 7, 8]

So that whichever source array is selected by the if statement is the array to be altered, and arrayProxy, though it may be used in later code, is not important for the purposes of the desired effect here.

I don't think pointers are the right solution here. I think a slight design modification would be better. What is desired is to alter one of the source arrays, so why not just do that? My solution would be this:

var sourceArray1 = [1, 2, 3, 4]
var sourceArray2 = [5, 6, 7, 8]

func someFunc(_ someArray: inout [Int]) {
    someArray.indices.forEach { someArray[$0] = 0 }
}

func caseTrue(_ someArray: inout [Int]) -> [Int]
{
    // The additional code from the if statement's `true` branch
    someFunc(&someArray)
    return someArray
}

func caseFalse(_ someArray: inout [Int]) -> [Int] {
    // The additional code from the if statement's `false` branch
    someFunc(&someArray)
    return someArray
}

let someCase = true // just for the sake of compiling a concrete case

//usage code - assuming arrayProxy is still needed for something in later code
let arrayProxy = someCase ? caseTrue(&sourceArray1) : caseFalse(&sourceArray2)

print("sourceArray1 = \(sourceArray1)")
print("sourceArray2 = \(sourceArray2)")

caseTrue and caseFalse can be local functions nested inside the method containing the if so they don't pollute code outside of the current context.

class AClass
{
    var sourceArray1 = [1, 2, 3, 4]
    var sourceArray2 = [5, 6, 7, 8]
    
    init() { }
    
    func someFunc(_ someArray: inout [Int]) {
        someArray.indices.forEach { someArray[$0] = 0 }
    }

    func aMethod()
    {
        func caseTrue(_ someArray: inout [Int]) -> [Int]
        {
            // The additional code from the if statement's `true` branch
            someFunc(&someArray)
            return someArray
        }

        func caseFalse(_ someArray: inout [Int]) -> [Int] {
            // The additional code from the if statement's `false` branch
            someFunc(&someArray)
            return someArray
        }
        
        let someCase = true // just for the sake of compiling a concrete case

        //usage code - assuming arrayProxy is still needed for something in later code
        let arrayProxy = someCase ? caseTrue(&sourceArray1) : caseFalse(&sourceArray2)

        print("sourceArray1 = \(sourceArray1)")
        print("sourceArray2 = \(sourceArray2)")
    }
}

If the bodies of caseTrue and caseFalse depend on local variables in aMethod, it's not a problem. Local functions capture variables from the surrounding context just like closures (in fact, in Swift they are basically just named closures). So declare the functions just before you need to call them, which means there might be some code above them inside of aMethod.

Answer 3

Found a solution but it looks strange:

var someProperty = [SomeClass]()
var someProperty2 = [SomeClass]()

func someFunc(someObject: inout [SomeClass]) {
    ...
    someObject = ... //
}

//usage code
let obj: UnsafeMutablePointer<[SomeClass]>
if someCase {
    obj = withUnsafeMutablePointer(to: &self.someProperty) { $0 }
    ...
} else {
    obj = withUnsafeMutablePointer(to: &self.someProperty2) { $0 }
    ...
}
someFunc(&obj.pointee)

So the "usage code" section is changed only. I didn't find a proper solution for some time because for example the following code produces "dangling pointer" warning:

obj = UnsafeMutablePointer<[SomeClass]>(&self.someProperty)

Also my solution sometimes causes this problem:

Thread 1: Simultaneous accesses to 0x7f85df805fc0, but modification requires exclusive access