<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="">I happen to agree with Jens, though Dave Abrahams (and Crusty) might disagree with me. The number one consideration for choosing between a value type and a reference type is “do I want value semantics or reference semantics?” If I want to talk about a particular shape, talk about “that one”, I can only do that if there’s some notion of identity. So yes, if that’s part of my app, I would start with reference types.</div><div class=""><br class=""></div><div class="">Now, that <i class="">doesn’t</i> have to apply to rendering. As shown in the presentation, if you’re generating the shapes, there’s no need to refer to a <i class="">particular</i> shape afterwards…especially if the shapes are immutable. Any <i class="">individual</i> shape is just data to be rendered. But if I want a command like “change the color of <i class="">that</i> square”, then I need a way to know what “that square” refers to, and an object with persistent identity—a class instance—is one way to do it.</div><div class=""><br class=""></div><div class="">You can get a notion of “identity” in ways other than reference semantics—say, by generating unique IDs that go with a particular shape, and then looking them up later. But it’s a perfectly fine choice to make your model use reference semantics.</div><div class=""><br class=""></div><div class="">All of that said, reference semantics do have traps: mutation makes things harder to test in isolation, and mutation with shared state makes things not thread-safe. So you have to decide what trade-off you want to make in your app.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 1, 2016, at 19:18, Jack Lawrence via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Jens: Why? There are significant benefits to value semantics for this type of problem, for the reasons laid out in the WWDC videos. It would be helpful to know why you disagree in this case—maybe there are solutions to the issues you’re thinking of.<div class=""><br class=""></div><div class="">Rick: I’d think that value semantics would be the right choice here. When you do a mutation, you would copy the state of the entire diagram. It should be efficient via COW, but if not you can implement you own more fine-grained COW types with isUniquelyReferenced(). This would allow you to easily support things like undo.<br class=""><div class=""><br class=""></div><div class="">Jack<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 1, 2016, at 4:32 PM, Jens Alfke via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 1, 2016, at 1:19 AM, Rick Mann via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">It seems like reference semantics are more appropriate here.</span><br style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">Yes, they are. (Just because structs exist doesn’t mean you have to use them everywhere.)</div><div class=""><br class=""></div><div class="">—Jens</div></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-users" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></blockquote></div><br class=""></body></html>