|
Hi there! I have a quick question about how memberwise initializers work when it comes to private properties. This stems off of another post of mine, and it's really just a question about how Swift is designed. Apple's documentation states:
This is great and all, but I am just wondering exactly why Swift is behaved to work like this. If you consider this struct, you would get an error because of what was just described in the documentation:
You cannot use the memberwise initializer here because the access level of the memberwise initializer was changed from However, if I were to write another struct, but with a custom initializer (that works exactly the same as a memberwise initializer with the exception of its access level) this time:
I wouldn’t get an error. This is because I’m overriding the memberwise initializer (along with its behavior just described in the documentation) and using the default access level of This is where my question comes in. What’s the actual benefit of Swift changing the memberwise initializer’s access level from I’m asking this because wouldn’t you design memberwise initializers in a way that could allow people to use them just like I used my custom initializer? If I could have a memberwise initializer with It’s a somewhat philosophical question (and perhaps the answer could be very simple and I am just overthinking this), but I just feel like understanding why Swift was designed in certain ways is going to help me understand what I am doing. I am confident that I understand everything surrounding these ideas very well, but I would just really like to dig a bit deeper. |
|
Joe ponders initializers:
You might see this in a different light if your initializer didn't use the same names as your Consider:
In this example, you eventually get an initialized If you allowed direct access via a memberwise initializer, any developer could bypass your customer's precise and stringent business rules. You marked them @rooster gives a nice explanation in a previous post. See -> Memberwise Initializers |
|
TAKE YOUR SKILLS TO THE NEXT LEVEL If you like Hacking with Swift, you'll love Hacking with Swift+ – it's my premium service where you can learn advanced Swift and SwiftUI, functional programming, algorithms, and more. Plus it comes with stacks of benefits, including monthly live streams, downloadable projects, a 20% discount on all books, and free gifts! Sponsor Hacking with Swift and reach the world's largest Swift community! |
|
Thank you for the help and suggestion. I get everything you are saying, but I just want to make sure you're having the same train of thought as I am. Just to clarify, when you say directly access properties, you don't mean that they are directly accessed through the memberwise init(), right? If I were to have a struct:
The color and price properties are not "directly" being accessed at the init() callsite, right? As in, the color param and the price param are the actual properties themselves within the struct. That idea doesn't even seem possible... or make sense. To specify, they're being accessed through parameters "indirectly" like how you would explicitly write a custom initializer:
Right? |
|
The more I think of it, I think I am actually understanding @Obelix's point... a little bit. I am going to look over it tomorrow. |
|
Oh! I think I am getting it a bit more. @roosterboy, just to confirm, when you (somewhat incorrectly) said that memberwise initializers "directly" set values from structs properties, and later corrected yourself, you actually meant that properties can be directly accessed outside of structs when using memberwise initializers because actually calling memberwise initializers requires them to not be private and have no private properties, thus we can directly access properties outside of structs. I think that's what you meant, right? |
|
@Obelix: Oh! I think I get it now! So, you're saying that if the memberwise initializer didn't change to a |
|
@roosterboy Thank you for suggesting the Swift Forums, as I have found someone asking the exact same question as me. They even added in virtually the same code as I did in my initial post. The first answer makes me think that this behavior could certainly have the potential to change. I guess it's just a default behavior. Any thoughts? |
|
Given that the proposal mentioned in that thread (SE-0018) has been in deferred status since 2016, I wouldn't get my hopes up for it being implemented any time soon. |
|
Haha, yeah. That's what I was talking about though. Glad to see that others were also thinking the same thing! I actually contacted the person today who proposed this and he said nothing happened! :) |
BUILD THE ULTIMATE PORTFOLIO APP Most Swift tutorials help you solve one specific problem, but in my Ultimate Portfolio App series I show you how to get all the best practices into a single app: architecture, testing, performance, accessibility, localization, project organization, and so much more, all while building a SwiftUI app that works on iOS, macOS and watchOS.
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.