Interestingly, while I don't see the same pointer in both places, I do see successive uses of withUnsafeBytes producing the same pointer:

import Foundation 
let data = "test".data(using: .utf8)! 
dump(data) 
data.withUnsafeBytes { (bytes: UnsafePointer<UInt8>) in 
    dump(bytes) 
}
data.withUnsafeBytes { (bytes: UnsafePointer<UInt8>) in 
    dump(bytes) 
}

I'm not quite sure what to make of that. Maybe withUnsafeBytes is doing a uniqueness check?

cc @phausler

“test” is small enough to be represented on the stack: so each call takes stack memory locations to pass into the closure (since the bytes are not valid past the call of the block)

This issue breaks code that depends on behavior "Immutable Data passes pointer pointing original memory to closure in withUnsafeBytes(_:)".
jpsim/Yams@bc13691

That is correct, it was technically the case before but was not commonly enforced (there were some subclasses of NSData that when bridged could do something similar). Now we have a more common case that has that behavior. This is almost the same change that happened to String when it gains the "smol" implementation.

It is worth noting that the cut-off for the byte pointer in the "smol" Data varies per architecture. If the payload can fit into the size of two pointers minus the storage for the length and the storage for the discriminator of the storage we opt for a non-heap implementation of Data.

Closing this, then, since it's intended behavior and not indicative of a performance problem.

I confirmed that this issue occurs only when Data is small.
Thanks!