<div>The purpose of an implicit internal, at least a big one, is for progressive disclosure. It allows learners to write useful types (and indeed entire apps) before they learn about access levels. Of the existing access levels only internal fits the bill.</div><div><br></div><div>I do agree that for optimal style internal should be written out; indeed I write out the access level for each member. I really don't see a need to force everyone to adopt that style though, as long as we have one consistent rule for what the default is.</div><div><br></div><div><br><div class="gmail_quote"><div>On Mon, Feb 13, 2017 at 07:38 Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 13 Feb 2017, at 14:24, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_5991282979943456022Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="m_5991282979943456022bloop_markdown gmail_msg" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><p style="margin:15px 0px" class="gmail_msg">–1 for me.</p><p style="margin:15px 0px" class="gmail_msg">IMO the current behavior reduces all that<span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="gmail_msg">internal</code><span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span>noise in large projects, where the author only makes a small part of the API public. Furthermore this will break the implicit initializer on structs and make it implicitly public. Leaving the initializer as<span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="gmail_msg">internal</code><span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span>while everything else is<span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="gmail_msg">public</code><span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span>as a workaround would be inconsistent solution, so that’s a no go. Personally I think that will introduce more noise than the current behavior, because we’ll have to repeat<span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="gmail_msg">internal</code><span class="m_5991282979943456022Apple-converted-space gmail_msg"> </span>all over the place in large projects. So in my eyes this would be a regression.</p><p style="margin:15px 0px" class="gmail_msg">P.S.: I’m curious what the core team has to say about this.</p></div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">I actually think “internal” is something which is worth calling out explicitly. It says that something is visible to other types in the project but not generally exported as part of the library’s API, which isn’t necessarily obvious. Implicit initialisers can be defined as having the same visibility as the type which they initialise.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Would be a huge source-breaking change though. I’m not sure anybody’s really 100% happy with our access modifiers, but it’s such a big change the core-team would understandably be reluctant to do it.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Karl</div><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>