[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization
jordan_rose at apple.com
Fri Jan 8 17:24:53 CST 2016
> On Jan 8, 2016, at 15:07, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jan 8, 2016, at 2:09 PM, David Owens II <david at owensd.io <mailto:david at owensd.io>> wrote:
>>> On Jan 8, 2016, at 11:21 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>> Actually it is internal, not private, and it exposes private properties via that internal initializer. It’s only in your own code, but I don't think it should be violating access control in that way.
>> Not for me in Xcode 7.2. Has this changed? Maybe it’s my app target? The implicit init() is only visible for me within the same file the struct is defined in.
> Wow, you’re right. It is enforcing access control. The implicit init is internal if there are no private properties, but private if there are private properties. I wonder if this has changed. If not, I’m embarrassed that I didn’t understand the current behavior in detail.
> I thought it was always internal. I’ve never actually used it for a struct with private properties before and I think the docs all say internal so maybe that is why. In any case, I’m glad to see that it is enforcing access control rules.
For the record (and independent of my dissent) it has always behaved this way. Access level of an implicit memberwise initializer is private if any stored property is private, internal otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution