<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;">Or, since many designs for submodules are possible... </span><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;">confident that there will be a good design for submodules</span></blockquote></div><p>We lack any real information on what Swift designs are possible. We can look to other languages for inspiration but they cannot be transplanted wholesale into Swift from a technical, practical, or cultural perspective. Rust isn't Swift.</p><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px;">Given, as some have said above, many different submodule designs are possible whatever the number of access levels, I would expect that we would not revisit this topic again for the foreseeable future, whatever the decision is.</span></blockquote></div><p>I think it would be appropriate to revisit this if we have new information. You have previously argued that there is substantial new information which you present as a rationale to revisit it now. I don't accept the premise, but I do accept the argument: if the circumstances change it's appropriate to take another look.</p><div><br class="Apple-interchange-newline"></div></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</div> <blockquote type="cite" class="clean_bq"><span><div><span style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !important; float: none;">Or, since many designs for submodules are possible, we can proceed to make the best decision *now* with respect to access levels, confident that there will be a good design for submodules whether or not there exist both scoped and file-based private access. That is to say, any future submodule proposal would be judged on how well it accommodates desired use cases if one type of private is removed, and any future design for submodules would be judged on how well it fits with the current set of access levels without duplicating functionality with a different syntax if both types of private are retained.</span><br style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !important; float: none;">One very important thing about the evolution process (IMO) is that decisions made aren't revisited without compelling changes in circumstances. It is highly unusual that fileprivate vs. private is now going through this process for a _third_ time. I submit that it is untenable that every version of Swift should consider a change to the access modifiers. Given, as some have said above, many different submodule designs are possible whatever the number of access levels, I would expect that we would not revisit this topic again for the foreseeable future, whatever the decision is. That is, the question being asked here is, is it better for Swift to have both fileprivate and private for all time, or one file-scoped private for all time?</span></div></span></blockquote></body></html>