There are two ways to give willSet semantics for a non-instantaneous modification (e.g. calling a mutating method on the property):
- You can do what Swift does today, which is to force the modification to happen to a temporary copy and then call
willSetimmediately before writing back. - You can call
willSetbefore the modification begins.
The second makes more sense to me abstractly, but it's totally incompatible with willSet getting passed the new value, and it's a radically different point in the execution of the program than the first (in our example of a mutating method, either before the call or after it). It would be unacceptable for the timing of the call to willSet to shift this much based only on whether newValue was used in the body. So we're locked into the first option.
There's really no way to optimize willSet given those semantics; it has to make a copy.