A catalog of warts would definitely be a very important thing to continue this discussion.<br><br>Keep in mind that one option that has been suggested on this list, and which has received some positive thoughts from some core team members, is to consider whether fileprivate vs. private is carrying its own weight or whether, given real-world experience, we would be better off rolling back to Swift 2 access levels.<br><br>The old design was self-consistent and kept things focused on what was exposed to consumers of a module vs. what was not. The possible answers to "who should be able to see or use this member?" were essentially: anyone at all, anyone who can modify the declaration by opening another file, anyone who can modify the declaration by scrolling up or down. Personally, within a module, I'm not convinced that anything more fine-grained actually helps you write safer code. For example, if the declaration is staring you in the face on the monitor, how much does it really do for you to have it inaccessible in another scope two lines down? In fact, with the possibility of submodules, I wonder if we can simplify even further: public or not. (public vs open is another discussion altogether; I'm leaving it aside at the moment.)<br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 2, 2016 at 09:56 Shawn Erickson 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">I think at this point we really need to build a concrete catalog of "warts" that cause implementation details to leak out of a module to consumers of a module (by extension submodule). I think that is the first things that should be looked at when considering making any changes to the access controls. I have a few code examples that I likely can pull together from real code that highlights some issues and I bet others do as well.<br class="gmail_msg"><br class="gmail_msg">If we can collect these and look at them more holistically it would be helpful.<br class="gmail_msg"><br class="gmail_msg">I think email is likely a week way to do this... hum...<br class="gmail_msg"><br class="gmail_msg">-Shawn<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Fri, Dec 2, 2016 at 7:51 AM Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" 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"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;white-space:pre-wrap" class="gmail_msg">Well, anyways, with Swift 3 it no longer is as simple as it is in Obj-C. New modifiers were introduced by request. I feel it's good and means everybody agrees Obj-C modifiers aren't sufficient for Swift.</div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Well… no ;-)</div><div class="gmail_msg">I'm not sure if there is a single thing in the universe where really everybody agrees on — right now, there is nothing more than a small group that has a vague agreement that there is room for improvement with the current access levels; most Swift users aren't even aware of this discussion at all (and most likely never will be ;-)</div>[In situations like this, I really dislike the restrictions of this medium… with something like a Wiki, it would be much easier to set up a table so that we could at least collect the opinions from the people discussing now.]</div><div class="gmail_msg"></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;white-space:pre-wrap" class="gmail_msg">What I mean, initial arguments should apply no more and I hope Apple will not be too rigid with current status.<br class="gmail_msg"></div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I agree on the latter — but it might be the case that fundamental changes to Swift won't be considered anymore</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;white-space:pre-wrap" class="gmail_msg">What I mean, though, the new introductions of access modifiers feel quite some "patchy".<br class="gmail_msg"></div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Yes… but imho your suggestion which adds additional levels makes it even more patchy:</div><div class="gmail_msg">"protected" might be familiar to some developers, but "inner" is just a new magic word tacked onto the language.</div><div class="gmail_msg">For me, this is actually the worst direction to take: Adding more and more new modifiers instead of really rethinking the topic from scratch.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div></div></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>
_______________________________________________<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>