On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote:
> > > On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution < > swift-evolution@swift.org> wrote: > > The "Access Control" section of the Swift 3 book says the following: > > You can mark an extension with an explicit access-level modifier (for > example, private extension) to set a *new default access level* for all > members defined within the extension. > > The behavior of "private extension" in Swift 3 was a deviation from that > model, justified because "private" as a default would have meant that > nothing in the extension could ever be called. But it was still contrary to > the model suggested by the Swift documentation. > > Given the highly restrictive behavior of "private" in Swift 3 and the > documentation quoted above, it seems unlikely that a developer would > intentionally use "private extension" to mean "please make all this stuff > visible to the entire file"—it would have worked, but it seems an odd way > to write it. If that were the intention, I think "fileprivate extension" > would have been more likely. > > I think the change to the behavior of "private extension" is in line with > the model proposed by SE-0169, in line with the documented behavior of > access control on extensions, and in line with user expectations. > -BJ > > > I understand your point. Another aspect of SE-0169 is that fileprivate > should be more rare and thus meaningful when used. The current behavior > stays true to the goal of making fileprivate rare. > > A top level private scope is effectively fileprivate so it is not totally > weird for the extension members to inherit the top level private scope. > > When extensions gain the ability to contain properties, we should not > allow the access level modifiers to the extensions in the same way protocol > extensions prohibit its use. > That idea would be my preference too, but it has been already written up as a proposal, considered, and rejected.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
