[swift-evolution] Proposal: Allow willChange and didChange observers on a property

[plx]

All else aside, isn’t `willChange` semantically-problematic anyways, due to it being possible to override `set` to modify the value that gets stored?

EG:

    class X {
      var font: UIFont {
         willChange {
           self.delegate?.fontWillChange(
            fromFont: oldValue,
            toFont: newValue
           )
         }
      }
    }

    class Y : X {
      override var font: UIFont {
        set {
           super.font = self.adjustedFontForBaseFont(newValue)
           // ^ e.g. to enforce monospace-digits trait
        }
      }
    }

…which isn't the nicest thing to do, but can be the easiest way to customize some of the UI widgets’ behavior.

> On Dec 6, 2015, at 11:28 PM, Nathan de Vries via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Dec 5, 2015, at 10:11 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> On Dec 5, 2015, at 4:00 PM, Nathan de Vries via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> It's currently possible to define either or both of the following observers on a property:
>>> willSet, called just before the value is stored
>>> didSet, called immediately after the new value is stored
>> ...
>> 
>>> This would mean the following observers could be defined on a property:
>>> willSet, called just before the value is stored
>>> willChange, called just before the value is stored if the value is different to the previous value
>>> didSet, called immediately after the new value is stored
>>> didChange, called immediately after the new value is stored if the new value is different to the previous value
>> 
>> I’m open to consider a change along these lines, but the proposal would have to be fleshed out more.  Presumably it would only work for equatable types, right?
> 
> I did a little hand-waving in that direction:
> 
> "Property types conforming to Equatable would be checked for the implicit guard via ==, otherwise it would fall back on the identity operator (===) for value and reference types that don't conform to Equatable."
> 
> Do you see an issue with falling back on identity if a property's type doesn't conform to Equatable?
> 
>> Also, can a property have these observers as well as the existing ones?
> 
> I don't see any issue with someone deciding to exhaustively add all observers to a property, but practically I'd only expect a subset (one) of them to be implemented. In my case I'd almost exclusively use didChange.
> 
>> Would it be possible to add *one of* didChange or willChange - since less is better?
> 
> I never use willSet at the moment and can't imagine myself using willChange, so it was really only included for completeness. I'd be fine with limiting the addition to didChange only, with my only concern being the inconsistency of not providing willChange.
> 
> —Nathan
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151207/9bc42a5f/attachment.html>