<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>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. </div><div><br></div><div>When ever I extend a swift standard type, I always make it "fileprivate" because I don't want to pollute autocomplete for that type. </div><div><br></div><div>fileprivate extension Int {</div><div> func double() -> Int {</div><div> return self*2</div><div> }</div><div>}</div><div><br></div><div>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.) </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>On Jun 27, 2016, at 3:06 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 27, 2016, at 13:00, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="bloop_markdown" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);"><blockquote style="margin: 15px 0px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); padding: 0px 15px; color: rgb(119, 119, 119); -webkit-margin-before: 0px;" class=""><div style="margin: 0px; -webkit-margin-before: 0px;" class="">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?<span class="Apple-converted-space"> </span></div></blockquote><p style="margin: 15px 0px;" class="">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).<span class="Apple-converted-space"> </span></p></div></div></blockquote></div><div>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 <i class="">like</i> the behavior of changing the default, then the feature should be removed.</div><div><br class=""></div><div>Jordan</div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>