[swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Jose Cheyo Jimenez cheyo at masters3d.com
Tue Jul 12 16:12:25 CDT 2016


> 	* What is your evaluation of the proposal?

-1 Strong. 

This proposal should go back to the drawing board because it is incoherent. 

This proposal claims to try to remove access modifiers but then also is trying to add them for:

> 	2.Allow access modifier when type-inheritance-clause is present.
> 	3 Access modifier on extensions should respect the modifier of the extended type and the protocol to which it should conform.

First it claims to remove them, then it claims to add them (2) and finally enforce them (3). 

Not to mentioned the proposed solution now has rules for enforce addition of modifiers (3).

There is more adding than removing. I don’t understand the benefit here.  

> " If you extend a private type, any new type members you add will have a default access level of private".


This is not longer accurate with the new definition of private. Top level extensions will have default access of fileprivate. 

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

no. I was never confused by access level on extensions. I don’t think this fixes anything but on the contrary. 

I don’t understand what the real problem this proposal is trying to address. 

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

nope. It takes away a really cool feature and adds weird rules. 

I think extensions are special and they should be treated as so. 

If I want to extend a type as private, let me mark the extension as private and treat the extension score as private. 

These rules are also going to force programers to write fileprivate a lot more often . 

private extension MyType {
	func1(){}
	func2(){}
}

with this proposal:

[MyType’s access level] extension MyType {
	fileprivate func1(){}
	fileprivate func2(){}
}

What if my type is internal? Now I have to write internal all the time. 

internal extension MyTyep{}


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

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

participated in the original thread. 



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


More information about the swift-evolution mailing list