|
1.- I understand, Structs are immutable, nonetheless the Swift compiler allows me to change Property "a" to 1, after it was already initialized to 10, were Structs immutable? why this is allowed? 2.- If the Swift compiler allows to change property "a" from the instance, why it doesn't allow to have the method "changeA" to modify "a" from within the Struct without adding the "mutating" modifier? It seems it is allowed to modify the property from the instance, but not from a method within the Struct, why? 3.- These are more conceptual questions, I fully understand that I can add "mutating" in front of the method and it will compile, but why I have to do that, if by default I am allowed to modify the property from outside the method after initialization, why the extra level of rigor with "mutating" to modify a property, that it is already declared as "var"? I am very much interested in the theory and concepts behing Struct's immutability, thank you very much for your help. |
|
Structs are value types. What does this mean? It means that an instance of a struct is the value. With a reference type, like a class, the instance is just a pointer to that value. This is the key to understanding struct immutability.
Structs are immutable in the same sense that an Similarly, given this code:
You can change the value of
changes the value of So what happens when you change the property of a struct declared with
It's a little misleading what's going on, to be honest. When you do Unless you use a
A neat feature of
And, in fact, behind the scenes a So that this method from our earlier
is the equivalent of this:
|
|
|
|
This is an interesting question and answer. If I understand what is said, I have another question: If there is a large struct with lots of / large properties and the code changes one of them, is a whole new struct created and the original one deleted? Can this cause a significant performance issue? I came up with an approach to testing this.
When I run this it displays:
If I remove the largeData property, it displays:
This clearly shows that there is a performance penalty for the largeData property. However, if a new copy of a is created every time, why doesn't the static counter increment? Thanks, Mark |
|
The compiler has ways of optimizing your code behind the scenes, so I don't think it would actually make 10 million copies. It's far more likely that the compiler recognizes that only that single This same question was posted on the official Swift forums and has some interesting answers there. Heck, in general you can find all sorts of interesting info on the official forums. |
|
Thanks for the information. I've done some more testing (heck, that's why it's called software engineering 😄.
By commenting out one or the other lines in the for loop, the code would either call a mutating function or do a direct assignment to a property. The largeData property was also commented in or out for the test. Mutating Function: With largeData: 48 seconds Without largeData: 24 seconds Direct Assignment: With largeData: 24 seconds Without largeData: 13 seconds Mark |
SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.
Sponsor Hacking with Swift and reach the world's largest Swift community!
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.