<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 19.07.2016 um 04:11 schrieb Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; 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;">Second, I would really like to see the methods match the open-ness or final-ity of their enclosing scope by default. Note: I also feel this way about access levels, which work this way except for public… I believe they should work the same way for public too (while keeping internal as the default level for top-level structures).</div></div></blockquote></div><div class="">afaics, I completely agree with your whole message, but this one is worth to be emphasized:</div><div class="">The effect of "public" should be propagated in the same way as "open"; I don't think there is any good reason to have two different models for similar concepts.</div><div class=""><br class=""></div><div class="">I think it would be even better to extend propagation up to module-level, and let the author decide what access levels are right for him — but that's most likely way beyond the willingness for compromise.</div></body></html>