mikeash.com pyblog/friday-qa-2015-07-17-when-to-use-swift-structs-and-classes.html comments

Tim - 2016-09-08 21:49:11

Thu, 08 Sep 2016 21:49:11 GMT

Alamaprabhu: "Looks like Structs are faster in terms of execution time."

Faster at what? They do different things, so you can't just replace one with the other.

It's like asking if a binary tree is faster or slower than a hash table. At some things, it's faster, and at other things, it's slower, but you'd never replace one with the other based on hearing "data structure X is faster than data structure Y". You pick the appropriate one for the semantics you need.

Edo Pelawi - 2016-06-14 07:05:14

Tue, 14 Jun 2016 07:05:14 GMT

Finally, beware of embedding reference types in value types, as terrible things can happen if you're not careful.

Interesting statement. I'm currently considering using RxSwift's Variables inside my Struct, and reading this made me realised that it fits this warning.

Do you have any references or documentations regarding value types owning reference types? Thanks in advance! :)

Allamaprabhu - 2015-09-08 06:16:59

Tue, 08 Sep 2015 06:16:59 GMT

Looks like Structs are faster in terms of execution time.Can you please explain more about that?.I feel its important decision to be considered while choosing types in swift.

Robert Payne - 2015-08-18 10:03:12

Tue, 18 Aug 2015 10:03:12 GMT

I may be wrong, but I believe reading somewhere that when Swift structs are copied that reference Objective-C values there could also be a huge hit on ARC semantics required to safely copy it (increment retain counts for each referenced value in the struct).

Wonder if anyone has dug in on that.

austinz - 2015-07-29 08:52:11

Wed, 29 Jul 2015 08:52:11 GMT

@Patrick: That's a cool idea, but you can have variables of (non-'class') protocol type whose semantics differ based on whether they're assigned struct or class instances.

In that case, the compiler can't tell at compile time whether a variable is going to have value or reference semantics, which means you'd have to tolerate your assignment symbol being misleading, or pick a third one for protocol types.

Patrick Weigel - 2015-07-25 02:38:21

Sat, 25 Jul 2015 02:38:21 GMT

So it finally hit me - since value type and reference type assignment are fundamentally different, Swift should use a different symbol for value type assignment and reference type assignment.

I have a suggestion below for the exact symbol to use in each case, but am open to other ideas. What do you think?

<- Use this for value type assignment
<• Use this for reference type assignment (• is option-8)

The compiler will know what assignment type each assignment is, so can return an error when you use the wrong one.

In the examples in the above post:
SomeClass *reference2 <• reference; // reference assignment
value.number <- 43; // value assignment
SomeClass *reference2 <- reference; // compiler error
value.number <• 43; // compiler error

Jonathan - 2015-07-24 14:52:52

Fri, 24 Jul 2015 14:52:52 GMT

Great article. As the "using a reference type inside a value type" is useful, but contains a potentially huge gotcha, do you think it should be something there is a compiler warning about? Or even an annotation so that the compiler (and the reader) know this was deliberate ?

I'm thinking of the poor developer who accidentally uses NSString instead of String...

Michael M. Mayer - 2015-07-20 04:44:45

Mon, 20 Jul 2015 04:44:45 GMT

Another great article and a wonderful complement to the Value Semantics WWDC session (414). This article was made doubly good by the reference to "tagged pointers" of which I had never heard. You've have filled a hole in my professional knowledge I never even knew existed, but for which I am deeply glad to have obtained.