<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 6, 2017, at 5:10 PM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 1em; border-left-width: 0.25em; border-left-style: solid; border-left-color: rgb(223, 226, 229); background-color: rgb(255, 255, 255);" class=""><div style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;" class=""><font color="#6a737d" face="-apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol" size="3" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md</a></font></div></blockquote><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box;" class="">What is your evaluation of the proposal?</li></ul></div></div></blockquote>Just barely +1.</div><div><br class="">It is a tough choice on whether this is a good change, because various future proposals which have been discussed would be impacted by the change:</div><div><br class=""></div><div>- If we add the ability in the future for extensions in the same type to declare stored properties, this influences the behavior of that feature (in potentially both good and bad ways)</div><div>- If we add further access controls above ‘private’ in the future, the weakening of private as strongest access control may affect the cleanliness/completeness of that design.</div><div><br class=""></div><div>Unlike the API design guidelines, access control levels don’t seem to have common usage patterns amongst the Swift community, with different desired levels of protection within a module (below ‘internal’). This makes the use of “file private” much more opinionated IMHO - widening private just enough that it might even become a common consideration that use of “fileprivate” is a potential code smell. The need to use “fileprivate” means that details of the implementation of a type may be selectively be exposed to other types, causing higher coupling, causing more code to be placed into a single file, and thus reducing overall maintainability. Similar to the use of IUOs, forced unwrapping and try! , this may still be desirable, and the complexity and impact can be managed appropriately.</div><div><br class=""></div><div>So +1 because the decision is being forced for the Swift 4 timeframe, without the ability to evaluate it in scope of a future Swift release that might focus on submodules or extensions with stored properties. Given a crystal ball, i might pick differently.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box; margin-top: 0.25em;" class="">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></div></blockquote>Yes, although I personally don’t like that we are still designing access control incrementally.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box; margin-top: 0.25em;" class="">Does this proposal fit well with the feel and direction of Swift?</li></ul></div></div></blockquote>I feel it fits well with current Swift, but is being forced to be evaluated in a vacuum in terms of future Swift direction. </div><div> <br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><ul style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box; margin-top: 0.25em;" class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></div></blockquote>In-depth study</div><div><br class=""></div><div>-DW</div></body></html>