|
Hi! I would like to clarify how memberwise initializers work/look like when it comes to using access control, specifically using private properties of structs. I fully understand how access control, memberwise initializers, and custom initializers work, but I'm getting a little bit stumped on why certain things behave how they do when playing around in Playgrounds. For example, if I were to create an However, when I create an After looking at these two different pieces of code, I just can't seem to understand how the memberwise initializer of the Please let me know if this needs more clarification. In essence, I'm really just wondering how memberwise initializers differ from the custom one I wrote. Perhaps the custom one does the same thing as a memberwise initializer but memberwise initializers work slightly differently? I don't really think that's right but... I don't know. Any help would be great! I just want to understand the little details like this! Have a great day! :)
|
|
A memberwise initiializer directly sets the values of your struct's properties. Thus, if a property is marked as If you create an initializer like in your second example, you are passing in a separate parameter that you then assign to the private property inside the init. This is only confusing in your example because you have named that parameter the same as the private property. If, instead, you were to do something like this:
or even:
you would see that what is being passed into the |
|
I got it! To simplify everything, I think I just had small a misunderstanding of how memberwise initializers work then. They DO directly set the value of a struct's properties, which clears up why I was confused. I was writing a slightly different custom initializer! :) |
SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure your entire paywall view without any code changes or app updates. Sponsor Hacking with Swift and reach the world's largest Swift community! |
|
Sorry, I wasn't entirely accurate with my earlier answer so allow me to clarify. It's not that the default memberwise initializer directly accesses the struct's properties. It's that the default memberwise initializer normally has an access level of internal but if there are private properties (without assigned default values) then the initializer also gets an access level of private. If the initializer is private you obviously can't call it from outside the struct, thus the error you are receiving. |
|
Oh! Got it. So, properties aren't "directly" accessed from the memberwise initializer call site. The actual error message makes a lot more sense now, since it describes how the actual |
|
I would like to clear this up in general, if you don't mind. If I were to make a struct and mark even just one of its properties as For example:
Based on your corrected answer, since the properties are both marked as However, if I were to write:
This code works great, without any errors. That must be because I am overriding the memberwise initializer and I am setting parameters equal to my actual properties, which (despite being private) can still be accessed indirectly. The only difference between these two scenarios is that I am using a memberwise initializer in one struct, which seems to conform to whatever access control of the properties (the behavior seems to be that if you have just one private property, internal will be overridden) compared to a custom initializer, which is indirectly accessing the private properties. Now the question is since the memberwise initializer gets marked as |
|
|
|
|
|
Sorry, I missed this question earlier... It's because only the default memberwise initializer automatically synthesized by the compiler gets assigned the same access level as the most restrictive property; your explicit initializer gets assigned |
|
Wonderful! I appreciate your help. That's what I was thinking, but it's nice to have that confirmed. I think it's all falling into place now and everything makes sense! :) I don't know if you would know the answer to this, but is there any reason why Swift memberwise initializers are designed in such a way? What's the benefit of being able to change its access level to My initial thought was that memberwise initializers obviously don't want to work with privately marked properties only to be used externally, but you can do exactly that with custom initializers. This is why I am a bit confused. That behavior is a result of the fact that you cannot make memberwise initializers with private properties, but what's the actual reason for it? |
SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure your entire paywall view without any code changes or app updates.
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.