<div dir="ltr"><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">> "</span><span style="line-height:1.5">1) Its not true. Its just about the reassignment. But for value-types in automatic the process of copy-change and assign."</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I understand that, but semantically it sure looks like it's true. It's an implementation detail, all about the copy-on-write optimization right? Why should the developer have to know about that?</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">> "</span><span style="line-height:1.5">2) because only value types need this keyword"</span></div><div>> "3) what's the problem here?"<span style="line-height:1.5"><br></span></div><div><br></div><div>Consistency. Makes the language harder to explain. To me the `mutating` keyword should either be used in classes as well or not used at all. Both would simplify things. But this is running off-topic from the original post though.</div><div><br></div><div>> "<span style="line-height:1.5">Can you elaborate this? Does not appear a real world problem."</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Not a specific example, but every line like `</span><span class="s1" style="line-height:1.5">something.a = </span><span class="s2" style="line-height:1.5">"anotherValue"` might or might not be relying on value semantics. After refactoring, the developer would have no choice but to read every line with `something` and judge whether value semantics was assumed or it was irrelevant. Really error prone. Any mistake would result in unintended reference sharing, race conditions etc. The actual bug might surface far from the originating issue.</span></div><div><span class="s2" style="line-height:1.5"><br></span></div><div><span class="s2" style="line-height:1.5">> "</span><span style="line-height:1.5">hu? Just check if the type is a struct or a enum! So will be a value type. Whats the problem here?"</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Of course, but you'd have to pause reading and jump to the definition each time. And keep two mental models when structures and classes are used together.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">> "</span><span style="line-height:1.5">No, the whole point of structs are not to be used in small and simple cases, not on Swift, in swift um Swift are first class citizen and can be use for complex data structure, like Array and Strings. You can make a private shared buffer behind the scenes."</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">It does certainly seem to be this way in practice. It was the impression I got from Swift's official docs: </span><span style="font-style:italic;line-height:1.5">"</span><span style="line-height:1.5"><i>The structure’s primary purpose is to encapsulate a few relatively simple data values.". </i>But now I realize it talks about other possible use cases.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">> "</span><span style="line-height:1.5">Try this one: </span><a href="https://developer.apple.com/videos/play/wwdc2015-408/" target="_blank" style="line-height:1.5">https://developer.apple.com/videos/play/wwdc2015-408/</a><span style="line-height:1.5"> </span><span style="line-height:1.5">( Protocol-Oriented Programming in Swift )"</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I enjoyed this one, but it's about inheritance vs. protocols. He changes classes to structures because he thinks it fits the model but he could have kept classes and still proved his point that protocols are more powerful and flexible. </span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">I called my attention though, at around 25:20m he shows `diagram.elements.append(diagram)` and says:<i> "</i></span><i>Now, it took me a second to realize why Drawing wasn't going into an infinite recursion at this point"</i>. That's kind of my point, these little surprises sprinkled around the code.</div><div><br></div><div><span style="font-weight:bold;white-space:nowrap">Brent Royal-Gordon:</span><br></div><div><span style="font-weight:bold;white-space:nowrap"><br></span></div><div><span style="font-weight:bold;white-space:nowrap">> "</span><span style="line-height:1.5">In a regular method, `self` is a regular (constant) parameter, but in a `mutating` method, `self` is `inout` so that it can be mutated and those mutations will reach the caller's copy of the instance. There's no need for an `inout` `self` on reference types, because the mutations are performed on the shared instance which both the caller and callee have a reference to, so `mutating` only really makes sense for value types."</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">But the `mutating` keyword isn't really needed to make `self` work this way for structures. It's actually not strictly needed at all. Another thing the `mutating` keyword "allows" is for the method to be able to reassign properties. I was advocating that `mutating` had only that meaning in order to be more consistent. Then it would be equally useful for classes to make APIs more clear with respect to mutation.</span></div><div><br></div>
</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 25, 2015 at 7:16 PM Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> However I could probably still agree with you if mutating was also used in classes. What's the point of having it only on structures?<br>
<br>
In a regular method, `self` is a regular (constant) parameter, but in a `mutating` method, `self` is `inout` so that it can be mutated and those mutations will reach the caller's copy of the instance. There's no need for an `inout` `self` on reference types, because the mutations are performed on the shared instance which both the caller and callee have a reference to, so `mutating` only really makes sense for value types.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</blockquote></div>