Top level `private` is understood as `fileprivate` about swift-book HOT 4 OPEN

This is expected as far as I am concerned: at the top level, private is always synonymous to fileprivate. We should hand it over to the swift-book folks.

cc @amartini51

Whether we still have room for the now source-breaking (albeit reasonable) behavioural exception you expected is worth discussing on the Swift forums, unless it already was.

from swift-book.

@amartini51 ping

from swift-book.

I'm not entirely clear what the documentation issue is here. It seems like it might be related to top-level private being understood by the compiler as fileprivate — so the inferred access level of testFunction(case:) is actually fileprivate, even though the extension is marked private. Is that correct and expected behavior by the compiler? I don't see that behavior described in SE-0025 or SE-0169.

from swift-book.

Is that correct and expected behavior by the compiler?

Yes, top-level private is an alias for fileprivate; they are semantically equivalent. I believe this is worth clarifying here. So the members of a private extension are fileprivate by default, not private. I think we should document this even if it happens to be an oversight (cc @DougGregor), because it has been the status quo since at least Swift 3, and would take a source-breaking evolution proposal to fix.

The book also states that the members of a private class, structure, or enumeration will have an effective access level of private, when the actual effective access level is fileprivate.

from swift-book.