I've run up against this too and had a similar thought. But on reflection I think the current "workaround" is actually the superior solution.<br><br>Even though in your example it's very clear that newValue is being mutated, if newValue were mutable, it would be possible to *accidentally* mutate it without warning or error if you are calling certain methods on newValue instead of using an assignment operator. For instance, in other contexts, I've made such a mistake more than once with array.append() when array is mutable, and I can never quite remember which of popFirst, dropFirst, etc., is a non-mutating term-of-art and which is mutating.<br><br>Of course, this can happen with any mutable value, but in all other circumstances you actually write "var something", whereas in your proposal you never have to write "var newValue". In fact, what you're actually proposing isn't even the equivalent of "var newValue"; it's to have newValue be of type `inout T` instead of `T`. I think such an implicit inout has no precedent in Swift and would be confusing to users.<br><br>By contrast, I think the current solution is very clear and hard to make a mistake with, although it is a little wordy.<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 11, 2016 at 10:50 PM Karl via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sometimes you would like to modify the value being set to a property before it is set.<br>
<br>
Currently, you would have to add a separate backing property and implement the getter and setter, even if you want to perform a simple bounds-check on the value being set and want to cap it to allowed values.<br>
<br>
e.g:<br>
<br>
var bounds : Bounds {<br>
willSet {<br>
// Cap the bounds<br>
newValue = newValue.capped(to: maximumSize)<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
}<br>
<br>
didSet {<br>
// Load the new bounds<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
}<br>
}<br>
<br>
Against the workaround you have to do currently:<br>
<br>
var _bounds : Bounds<br>
var bounds : Bounds {<br>
get { return _bounds }<br>
set {<br>
// Cap the bounds<br>
_bounds = newValue.capped(to: maximumSize)<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
<br>
// Load the new bounds<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
// Some comments to demonstrate noise if we were doing more processing<br>
}<br>
}<br>
<br>
Currently, the capping in willSet is a compile-time error because `newValue` is a let constant, but I find that breaking your accessor code up in to willSet/didSet blocks allows for greater readability, especially when you have lots of processing to do (in the workaround example, the validation/preprocessing code and effects/postprocessing code are only separated by a comment). I propose that, at least for the scope of willSet (and *not* didSet, if we can manage that), that the variable should be mutable.<br>
<br>
Any thoughts?<br>
<br>
Karl<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>