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
> <[email protected]> wrote:
>
>
>> On Jun 27, 2016, at 13:00, Adrian Zubarev via swift-evolution
>> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
