Attachment: Download

relates to:

• SR-1956 withUnsafePointer shouldn't take its argument as inout
• SR-4929 Support non-inout homogeneous tuple argument conversion to UnsafePointer

Issue Description:

The following code shows the inconsistency in passing values to UnsafeRawPointer:

func get(_ pointer: UnsafeRawPointer, at index: Int) -> Int {
let a = pointer.bindMemory(to: Int.self, capacity: 6)
return a[index]
}

var varArray = [Int](repeating: 0, count: 6)
var varTuple = (0, 0, 0, 0, 0, 0)

let letArray = [Int](repeating: 0, count: 6)
let letTuple = (0, 0, 0, 0, 0, 0)

// Array can be passed directly, automatically takes address.
_ = get(varArray, at: 2) // okay
_ = get(letArray, at: 2) // okay

// When explicitly taking address, can only pass mutable variables.
_ = get(&varArray, at: 2) // okay, but seems inconsistent
_ = get(&letArray, at: 2) // fails: & not allowed

// Passing tuple instead of array fails.
_ = get(varTuple, at: 2) // fails (wrong type)
_ = get(letTuple, at: 2) // fails (wrong type)

// Adding & to pass a tuple only works for mutable values. Having to
// pass the address using & means that any methods calling this must
// be mutating, even though they don't mutate.
_ = get(&varTuple, at: 2) // okay, but forces mutating
_ = get(&letTuple, at: 2) // fails: cannot pass immutable value

Getting an UnsafeRawPointer should not require use of &, as that forces all code calling it to be mutating. Having a special case for array also doesn't make sense, as the idea of UnsafeRawPointer is that we're interpreting that memory content as whatever we want. This needs to be fixed. This is related to SR-4542, as a C array is imported as tuples, and thus read-only access is not possible without being mutating.

Proposal:

• Never require & when passing value to UnsafeRawPointer.

• Always require & when passing value to UnsafeMutableRawPointer.