<div dir="ltr">I understand and I am aware of this proposal. I only raised this since collections are a primitive object type that are used quite frequently in swift. I think it would be acceptable to introduce a generic way of knowing when an item was added, updated or removed which could be demoted with set and get.<div><br></div><div>I think the pros outweigh the cons. Previous proposals such as default initialisers are either too complex / niche or can already be done via the swift language. So are better implemented with property behaviours.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><b><font color="#cc0000">___________________________________</font></b></p><p><b>James⎥Lead Engineer</b></p><p><b><font color="#cc0000"><a href="mailto:james@supmenow.com" target="_blank">james@supmenow.com</a>⎥<a href="http://supmenow.com" target="_blank">supmenow.com</a></font></b></p><p><b><font size="2">Sup</font></b></p><p><b><font size="2">Runway East
</font></b></p><p><b><font size="2">10 Finsbury Square</font></b></p><p><b><font size="2">London</font></b></p><p><b><font size="2">
EC2A 1AF </font></b></p></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jan 13, 2016 at 4:45 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Jan 12, 2016, at 8:07 PM, Dave via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> 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.<br>
>><br>
>> Charles<br>
> Also, good points. I guess my idea then is:<br>
> “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)<br>
> “did/willUpdateAtIndex”, “did/WillInsertAtIndex”, and “did/WillRemoveAtIndex” for single elements<br>
> “did/willUpdateInRange”, “did/WillInsertInRange”, and “did/WillRemoveInRange” for multiple elements<br>
><br>
> 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:<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
-Chris<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
</div></div></blockquote></div><br></div>