<div dir="ltr"><div><div><div>When in doubt, go with a struct. Probably nineteen types out of twenty I write are structs. Swift really is optimized with the assumption that you’re working with structs, that’s why almost everything in the standard library is a value type. Structs always pack contiguously into arrays, while arrays of classes can get bridged to a non-contiguous NSArray. Code that uses classes tends to be hard to read since `let` and `var` cease to convey useful information about mutability. Classes also open up cans of worms with strong and weak ownership cycles and all that crap which is almost completely avoidable if you know how to use value types well.<br><br></div>The only reason to use a class is if you really, really need reference semantics — i.e., the instance does not have a clearly defined owner, and you want any changes to the instance to be reflected in all of its owners. This is rare though, and more often than not this is a code smell that something is wrong with the larger design. Another case is when the instance manages some kind of external resource, like a memory buffer, and you have no other way of untangling the resource management from the life cycle of the instance. This is why Swift array buffers are classes (though the Array type itself is a struct which contains the buffer class).<br><br></div><div>Another case where a class *might* be appropriate is when your type contains many many stored properties, that pushing and popping them off the call stack by value would be slower than pushing a reference. That’s usually a sign that you’re not making enough use of static or computed properties though. The pass by value cost is also not as important as you might think — small functions will get inlined by the compiler, while large functions don’t care since the function call cost will be dwarfed by the cost of executing the actual function body.<br><br></div><div>Inheritance and polymorphism are *not* a good enough reason to use classes; that’s what extensions and protocols are for.<br><br></div><div>Don’t use a struct as a scoping container; use an enum for that. Some people scope things to structs because they don’t remember that enums can be used as a namespace, but the swift idiom is to use an enum for this, not a struct.<br></div><div><br></div><div>tldr; structs and enums are the preferred native Swift object, classes are really only there for programmers coming from other languages who are used to thinking in terms of reference types.<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 1:16 PM, Vitor Navarro via swift-users <span dir="ltr"><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I know this question is probably done a thousand times, but I wanted to hear from Swift dev community.</div><div><br></div><div>I think both of them have right places for usage depending on the occasion but documentation, WWDC and the internet give opposite answers regarding this.</div><div><br></div><div>Do you guys have any guideline regarding usage here?</div><div><br></div><div>Thank you.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Vitor Navarro</div></font></span></div>
<br>______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-users</a><br>
<br></blockquote></div><br></div>