Defining value semantics

What’s nice about about primitive value types like Color or Int is not the assign-by- copy behavior itself, but rather the guarantee this behavior creates.

This guarantee is that the only way to affect a variable’s value is through that variable itself. If a type promises that, then the type supports value semantics.

To test if a type supports value semantics, consider it in a snippet like the following:

var x = MysteryType() var y = x

exposeValue(x) // => initial value derived from x

// {code here which uses only y}

exposeValue(x) // => final value derived from x

// Q: are the initial and final values different?

If the code which “uses only y” can affect the value of x, then MysteryType does not support value semantics.

One benefit of value semantics is that they aid local reasoning, since to find out how a variable got its value you only need to consider the history of interactions with that variable. When using value semantics, you work in a simple world, where variables have values and those variables do not affect each other.