[swift-evolution] Custom didSet methods

[Chris Lattner]

On Jan 12, 2016, at 8:07 PM, Dave via swift-evolution <swift-evolution at swift.org> wrote:
>> What KVO did was to offer an NSKeyValueSetMutationKind enum containing constants for insertion and removal as well as OR and AND operations with other sets. If you don't want to do that, another possible interface could be to provide two ranges, one representing the range of the affected region before the change, and another representing it afterward. If you had an empty range for "before" and a non-empty range for "after", that would represent an insertion. The reverse would be removal, and anything else would be a replacement of some kind.
>> 
>> Charles
> Also, good points. I guess my idea then is:
> “did/willUpdate”, “did/willInsert”, and “did/willRemove” for when you don’t care about which element was changed (and for types that aren’t indexable anyway)
> “did/willUpdateAtIndex”, “did/WillInsertAtIndex”, and “did/WillRemoveAtIndex” for single elements
> “did/willUpdateInRange”, “did/WillInsertInRange”, and “did/WillRemoveInRange” for multiple elements
> 
> That’s a lot of new keywords, though… Oh! What if it was *only* did/willUpdate, did/willAdd, and did/willRemove, and they were overloaded with (), (atIndex: Index), and (inRange: Range<Index>) forms? Like this:

Just a random comment on this thread:  our desire is to introduce property behaviors, and “demote” things like property observers into library features.  This is great because it makes it much easier to extend these capabilities without hacking on the compiler, and will allow you to define custom behaviors in your own code.

I don’t know if the first round of behaviors will actually allow us to eliminate willset/didset though, simply given that they need to poke at the super implementation.  That said, we’d rather work towards fixing those problems: proposals to make the existing property observers richer aren’t likely to be accepted.

-Chris