[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Martin Waitz]

Well summarised Tino, I agree with all arguments.
Strong -1 from me, too.

> Am 11.04.2017 um 08:48 schrieb Tino Heth via swift-evolution <swift-evolution at swift.org>:
> 
> -1 (strong)
> 
> I think I've read all messages and haven't much to add — so just to sum up my concerns in order:
> — It makes access control more complicated
> — It adds no power to the language
> — It diminishes the need for fileprivate without making it redundant
> — It is a mockery for SE-0025
> — It is a breaking change

If we want to encourage separating several aspects of one type into multiple extensions, then we should try a different approach.
When we allow to also introduce new member variables in extensions, then we could make them private while still keeping them local to the member functions which access them.

This approach has other downsides but I think we can cope with them.
Biggest disadvantage would be that the storage size is not immediately visible from the type definition.
We could require some marker (`partial class` / `extension class` / whatever) so that everybody can immediately see that there may be extensions with additional storage.

E.g.:

    partial class Foo {}

    extension Foo {
        private var i = 0
        func bar() {
            print(i)
            i += 1
        }
    }
    extension Foo {
        private var j = 1
        func baz() {
            print(j)
            j -= 1
        }
    }

When we want any distinction between `private` and `fileprivate`, then these two extensions should not see each others private members.
Of course the other workaround would be to remove the distinction altogether and make private an alias for fileprivate.

— 
Martin