Nitpicking: Shouldn't UnsafeMutablePointer be called UnsafeMutatingPointer?

Instances of UnsafePointer<T> and UnsafeMutablePointer<T> are both mutable (if they are vars), but only the latter is capable of mutating the memory that it points to.

let mp1 = UnsafeMutablePointer<UInt8>.allocate(capacity: 123)
var mp2 = UnsafeMutablePointer<UInt8>.allocate(capacity: 456)

var p = UnsafePointer<UInt8>(mp1)
p = UnsafePointer<UInt8>(mp2) // We can mutate the non-mutable pointer `p`,
mp2 = mp1 // just like we can mutate the mutable pointer `mp2`.

// One thing we cannot mutate is the memory that `p` points to:
// p.pointee = 123 // ERROR: Cannot assign to property: 'pointee' is a get-only property
// So `p` is a non-mutating pointer, not a non-mutable pointer.

// We can mutate the memory that `mp1` points to:
mp1.pointee = 78 // This is ok even though mp1 is a let constant, because
// it is not `mp1` that is mutable, it is the memory that it points to.
// And we cannot mutate `mp1` even though the name of its type is "…Mutable…":
// mp1 = mp2 // ERROR: Cannot assign to value: 'mp1' is a 'let' constant
// So `mp1` is a mutating pointer, not a mutable pointer.

mp1.deallocate()
p.deallocate()
3 Likes

You are correct. "Mutable" refers to the memory object not the pointer. If we could go back in time it might be something worth nitpicking.

Can't we rename the types and provide type aliases for old name and deprecate those? Or will it cause to much code churn?

1 Like

An API that's been in widespread use across multiple releases shouldn't be changed unless it's causing a real practical problem for developers or future language development. A hypothetical problem of unclear semantics can be solved in the documentation.

1 Like

Good catch and +1 from me. Clarity over “that ship has sailed”. :slight_smile:

P.S. Personally I think APIs should constantly evolve and improve even if in widespread use. I like how Apple keeps updating Cocoa APIs — deprecating old stuff, improving naming, nesting types, etc.

3 Likes