<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">I am glad that “private” will become usable again in Swift 4. This eliminates most of the pain caused by “fileprivate”.</div><div class="gmail_extra"><br></div><div class="gmail_extra">However, I do not understand why this solution was chosen over renaming the keywords. The discussion of alternatives here does not mention it, and the only explanation given after SE-0159 is that renaming would cause “churn”. Yet that renaming would be completely automatable by a migrator with no change to semantics, whereas SE-0169 will require developers to manually investigate each occurrence of “private” to see if the new meaning is still appropriate, and introduce helper types to hide implementation details where it is not.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Furthermore, I remain concerned that the mere act and fact of defining “private” specifically to hide implementation details from other types in the file will lead developers to put unrelated types together in a single file, because that appears to be the intended purpose of the keyword.</div><div class="gmail_extra"><br></div><div class="gmail_extra">At a meta-level, since mistakes like SE–0025 will be much more costly in the source-stable future, we ought to consider adding a step to the Swift Evolution process whereby accepted proposals are implemented in a beta version of Swift, and a second review period can happen if new problems become apparent in actual usage that were unforeseen during the initial discussion. That way we are much more likely to catch emergent issues before release.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nevin</div></div></div>