[swift-users] Class vs Structures

Taylor Swift kelvin13ma at gmail.com
Thu Jun 29 13:41:52 CDT 2017

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.

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).

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.

Inheritance and polymorphism are *not* a good enough reason to use classes;
that’s what extensions and protocols are for.

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.

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.

On Thu, Jun 29, 2017 at 1:16 PM, Vitor Navarro via swift-users <
swift-users at swift.org> wrote:

> Hi,
> I know this question is probably done a thousand times, but I wanted to
> hear from Swift dev community.
> 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.
> Do you guys have any guideline regarding usage here?
> Thank you.
> Vitor Navarro
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170629/3db78346/attachment.html>

More information about the swift-users mailing list