[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[Matthew Johnson]

Sent from my iPad

> On Jan 8, 2016, at 5:24 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>>> 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> wrote:
>>>> 
>>>> 
>>>> On Jan 8, 2016, at 11:21 AM, Matthew Johnson <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.

Thanks for setting the record straight.  I don't think any of the docs mention this and I had never tried it so I didn't realize this.  It's a bit embarrassing as I feel like it is something I should have discovered while writing the proposal.

> 
> Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160108/e9ef5535/attachment.html>