[swift-evolution] [Proposal] Revising access modifiers on extensions

[Jose Cheyo Jimenez]

I would be against removing access modifiers on extensions. I actually don't see anything wrong with the way extensions work with modifiers right now.  Consistency for consistency's sake is never a good measurement if it is not addressing a pain point. 

When ever I extend a swift standard type, I always make it "fileprivate" because I don't want to pollute autocomplete for that type. 

fileprivate extension Int {
   func double() -> Int {
       return self*2
   }
}

My understanding is that private / fileprivate was renamed/introduced to help with extensions. I don't think extensions need anymore complexities. I would hardly ever use private in swift 3 for example (when it gets implemented.) 





> On Jun 27, 2016, at 3:06 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jun 27, 2016, at 13:00, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I still have no idea why you want to make this change, other than “putting an access modifier on an extension is different from putting an access modifier on a type”. Are you trying to hide protocol conformances that would be otherwise public? 
>> In my proposal I cannot hide a public protocol conformance. Its not possible with normal types and it shouldn’t be possible with extensions as well. (Correct me if I’m wrong.) I really want the same access control behavior with extensions like whit classes, enums and structs. For new Swift developers such consistency would be great, because they won’t need to learn another access control behavior (second one goes to protocols). 
>> 
> 
> If you want consistent behavior, the proposal should just be "remove access modifiers from extensions". That way, access for members follows the same defaults as in the original type. The only purpose for access modifiers on extensions is to change the default, so if you don't like the behavior of changing the default, then the feature should be removed.
> 
> Jordan
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/a1615686/attachment.html>