[Review] SE-0159: Fix Private Access Levels


(Davor Jankolija) #1

What is your evaluation of the proposal?

+ 1.

Don’t like to admit it but i favored the fileprivate modifier when it was introduced. Alas more experince with Swift has meant that I now very often catch myself changing private to fileprivate if for nothing else then to allow protocol conformance through extensions in the same file. Even though this may not be a good enough reason to make me go with supporting the proposal, the fact that access modifiers are fundamental to most modern PLs and fileprivate vs private as is is now adds too little while on the other hand adds another access modifier which IMHO should be simple and allow encapsluation (as some have said, internal and public are actually enough to achieve this) means for me this is something worth reverting.

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

Yes.

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?

Most other languages encapsulate based on type and inheritance, so this strays a bit by making private extend beyond the class definition itself. However, no other language I’ve used make use of extensions the way Swift does so it makes sense in a Swift environment.

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

Followed both the original conversation added fileprivate as well as the other conversations which led to this proposal.

- Davor


(Goffredo Marocchi) #2

Sent from my iPhone

What is your evaluation of the proposal?

+ 1.

Don’t like to admit it but i favored the fileprivate modifier when it was introduced. Alas more experince with Swift has meant that I now very often catch myself changing private to fileprivate if for nothing else then to allow protocol conformance through extensions in the same file. Even though this may not be a good enough reason to make me go with supporting the proposal, the fact that access modifiers are fundamental to most modern PLs and fileprivate vs private as is is now adds too little while on the other hand adds another access modifier which IMHO should be simple and allow encapsluation (as some have said, internal and public are actually enough to achieve this) means for me this is something worth reverting.

The current situation does not prevent anyone from expressing themselves/implementing their preferred patterns. I am really not sure why we should revert a change which allowed people that value and need scope based access to do their job?

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

Yes.

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?

Most other languages encapsulate based on type and inheritance, so this strays a bit by making private extend beyond the class definition itself. However, no other language I’ve used make use of extensions the way Swift does so it makes sense in a Swift environment.

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

Followed both the original conversation added fileprivate as well as the other conversations which led to this proposal.

- Davor

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

···

Sent from my iPhone

On 21 Mar 2017, at 20:36, Goffredo Marocchi <panajev@gmail.com> wrote:

On 21 Mar 2017, at 16:23, Davor Jankolija via swift-evolution <swift-evolution@swift.org> wrote: