I&#39;ve run up against this too and had a similar thought. But on reflection I think the current &quot;workaround&quot; is actually the superior solution.<br><br>Even though in your example it&#39;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&#39;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 &quot;var something&quot;, whereas in your proposal you never have to write &quot;var newValue&quot;. In fact, what you&#39;re actually proposing isn&#39;t even the equivalent of &quot;var newValue&quot;; it&#39;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 &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; 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>