<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">If you're serious about your proposal, you need to come up with a realistic plan for phasing out the current struct semantics for everyone, in every use case that they have.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 26 déc. 2015 à 11:14:44, Lino Rosa via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">> "</span><span style="line-height:1.5" class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">> "</span><span style="line-height:1.5" class="">2) because only value types need this keyword"</span></div><div class="">> "3) what's the problem here?"<span style="line-height:1.5" class=""><br class=""></span></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">> "<span style="line-height:1.5" class="">Can you elaborate this? Does not appear a real world problem."</span></div><div class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">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 class=""><span class="s2" style="line-height:1.5"><br class=""></span></div><div class=""><span class="s2" style="line-height:1.5">> "</span><span style="line-height:1.5" class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">> "</span><span style="line-height:1.5" class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">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" class="">"</span><span style="line-height:1.5" class=""><i class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">> "</span><span style="line-height:1.5" class="">Try this one: </span><a href="https://developer.apple.com/videos/play/wwdc2015-408/" target="_blank" style="line-height:1.5" class="">https://developer.apple.com/videos/play/wwdc2015-408/</a><span style="line-height:1.5" class=""> </span><span style="line-height:1.5" class="">( Protocol-Oriented Programming in Swift )"</span></div><div class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">I called my attention though, at around 25:20m he shows `diagram.elements.append(diagram)` and says:<i class=""> "</i></span><i class="">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 class=""><br class=""></div><div class=""><span style="font-weight:bold;white-space:nowrap" class="">Brent Royal-Gordon:</span><br class=""></div><div class=""><span style="font-weight:bold;white-space:nowrap" class=""><br class=""></span></div><div class=""><span style="font-weight:bold;white-space:nowrap" class="">> "</span><span style="line-height:1.5" class="">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 class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class="">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 class=""><br class=""></div>
</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Dec 25, 2015 at 7:16 PM Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""></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 class="">
<br class="">
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 class="">
<br class="">
--<br class="">
Brent Royal-Gordon<br class="">
Architechies<br class="">
<br class="">
</blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k5j-2BBtSgVyF5S-2Be8jxJ7FQS-2B71lICM2iH1sSIcxreLEmgrwCOa9Urw59oDeE-2BQvW6gT49GVMsmorDfcO-2BFI7B5BkoTjfzmuaMgoIiWdPJk2MlUWfJHK-2F6Gsl0xoTlv-2BkAeNIE4z0PhwwkrYgtZQi-2F8XkMyws1cu-2BBpJsJNp-2B97QTA4aLbg2ktmZrAcaUMMZhH4-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>