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

[Tino Heth]

-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
For me, it's not about the complexity itself (it's not terrible huge, after all), but I believe in the beauty of simplicity, which is already quite flawed.
— It adds no power to the language
The proposal solves no real problem, but rather encourages a certain style of programming, which is quite popular among authors of styleguides, but has no clear net gain.
— It diminishes the need for fileprivate without making it redundant
It would be nice to get rid of an access level, but having four common ones and fileprivate as an exotic outlier doesn't feel right for me.
— It is a mockery for SE-0025
I never liked "new private", but it was decided that this sort of encapsulation is important enough to justify 33% increase in the number of access levels, so I don't like to see this watered down
— It is a breaking change
For me personally, that doesn't really count as an argument on its own, and I would gladly take the inconvenience of incompatibility in exchange for a tiny improvement of the language; but in combination with the other points, it increases opposition.

I spend some time thinking about nested extensions (which would achieve the goal of this proposal naturally) and think that SE-0169 would lead to some questionable possibilities of short-circuiting access control:

class Outer {
	private class Inner {
		private var x = 0
	}
}

/*
.
.
.
*/

extension Outer.Inner {
	public func f() {
		print(x)
	}
}

As I read the proposal, there is no doubt that this would be allowed — but without that detailed information, I'm not sure if anybody would expect that two levels of private still is not enough to keep something secret…

- Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170411/b79b7f43/attachment.html>