<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><p class="airmail_on">Am 13. Juli 2016 um 18:49:11, Jordan Rose (<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>) schrieb:</p> <div><blockquote type="cite" class="clean_bq" 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;"><span><div><span style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; 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(255, 255, 255); float: none; display: inline !important;">Hi, Adrian. I have to agree with everyone else that the proposal is unclear. “Remove access modifiers from extensions” sounds like you just aren’t allowed to write them at all, but your proposal seems to be more “access modifiers on extensions set a maximum level of access for members, like they do for types, and do not change the default”. (Plus a bit about conformances.)<span class="Apple-converted-space"> </span></span></div></span></blockquote></div><p>I probably misunderstood you in the original proposal thread here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022341.html</p><p>I renamed the proposal by thinking that would be the correct technical issue I was addressing. I apologize for any confusion the title have caused.</p><div><div><blockquote type="cite" class="clean_bq" 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;"><span><div><span style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; 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(255, 255, 255); float: none; display: inline !important;">I am against the latter proposal because I don’t think people should think of extensions as first-class entities. There is really no such thing as a “public extension” or a “private extension” because extensions cannot be referred to in the language and do not have any run-time representation. The access control that really matters is that of the original type, and I wouldn’t want to force people to repeat it here.<span class="Apple-converted-space"> </span></span></div></span></blockquote></div><p>Just for the record:</p><p>- What happens under the hood if I extend a specific type?</p><p>- Do you create only one single `extension bag` and sort members by the access modifiers from all different extensions?</p><p>- How do these members reference to other extensions members which are visible only inside a specific extension?</p><div><div><blockquote type="cite" class="clean_bq" 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;"><span><div><span style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; 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(255, 255, 255); float: none; display: inline !important;">I am personally all right with the idea of removing access modifiers from extensions altogether, but I know several people like that feature a lot, and I don’t think it passes the criterion of being “a significant enough problem to warrant a change in Swift”.<span class="Apple-converted-space"> </span></span></div></span></blockquote></div><p>I don’t mind if the proposal gets rejected now, at least I’ve seen a bit more feedback now.</p><p>PS: One think I might still would want to solve with this proposal is the default access modifier on extensions with protocols.</p><p>If you’d think about the rules in the proposed solution, aren’t they exactly how a default access modifier still can be present when there is conformance involved? </p><div></div></div></div></body></html>