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

[Gwendal Roué]

> 	• What is your evaluation of the proposal?

Positive.

I could not stress enough how the attitude behind such a proposal is *positive*.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. private / fileprivate had a tremendous design issue: developers would jump from private to fileprivate just to shut up the compiler. Now this won't happen unless an actual design decision.

> 	• Does this proposal fit well with the feel and direction of Swift?

Yes.

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Reasonably well.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Have pity. It's very difficult to follow this topic that has generated thousands of messages. I vote +1 because the proposal looks reasonable, balanced, and focused on regular developers. <rant>I wish people who insists on splitting hairs about access control would give us a break already.</rant>

Gwendal Roué


> Le 11 avr. 2017 à 13:00, David Hart via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
> On 11 Apr 2017, at 08:48, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> -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.
> 
> While your other points are defendable, I have to disagree here. It does bring value to a population of developers (me included) for whom that style of programming adds a lot of readability. It's part of style guides for a reason.
> 
>> — 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.
> 
> Doesn't the argument of progressive disclosure sway you here? open is already an outlier that only library authors will play with, and that's a good thing. It reduces the number of access level truly useful on a day to day basis, while leaving the others for more narrow purposes.
> 
>> — 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
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution