I think value semantics are best summarized by an out-of-place transform function:
func transformedCopy<T>(
_ x: T, transform: (inout T)->()
) -> T {
var result = x
transform(&result)
return result
}
That implementation is correct if and only if T has value semantics.
• • •
More concretely, a type T has value semantics if and only if, for all possible instances of T and all possible transform operations (edit: which do not mutate anything other than the inout argument), the use of transformedCopy does not modify its argument.
Thus, in the following snippet:
var x: T = ...
// 1
let y = transformedCopy(x){ ... }
// 2
If at lines 1 and 2 we print out a complete description of all salient features of x, and they are not identical to each other, then T does not have value semantics.
In particular, if there exists any possible x and any possible transform (edit: same caveat as above) for which they are different, then the type does not have value semantics.
• • •
Edit:
Of course, if transform captures and mutates the variable which is being passed in as x then we get the same situation as in MutableReference above, so we ought to rule that out.
But even if it doesn’t, we can still get situations like this:
var a: Int = 1
var b: Int {
get { a }
set { a = newValue }
}
print(b) // 1
let c = transformedCopy(b){
a += 1
$0 += a
}
print(b) // 2
So indeed the definition is quite slippery.
I do, however, still maintain that the implementation of transformedCopy is correct if and only if T has value semantics. Indeed, functions like that are exactly and precisely where I would want to use a T: ValueSemantics constraint.