<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Tony resumed very well my thought on this proposal. I'd like to add that even with all its complexity, it does not solve any of the issues introduced with SE-0025 and that the recent proposals have tried to fix. At the heart, SE-0159 and SE-0169 try to bring back a good safe-default private modifier. This proposal does not do that and a custom access level can never be a "default".</div><div><br>On 14 Apr 2017, at 23:20, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I hate to be negative, since you've clearly put a lot of great thought into this. But ultimately, I feel that this is *significantly* more complicated than the problem of access control needs to be in Swift. I'm struggling to think of another programming language that supports this fine-grained level of detail.<div><br></div><div>The ability to create custom groups sounds like something that a very small minority of Swift writers would take advantage of. Meanwhile, it sounds like it would have the potential to greatly increase the learning curve of someone coming into a new code base, because now they have to potentially learn a whole new set of bespoke custom access modifiers that the authors decided to create.</div><div><br></div><div>I can only imagine that this would create a number of "dialects" of Swift, which the core team strongly wants to avoid (and which we should want to avoid as well). How would these access groups be namespaced? Are they restricted to only being usable within their module? (Meaning that they would effectively be erased when referencing a type/member with such groups outside that module?) If not, how do we guarantee that access groups are unique across code bases importing them from multiple modules? Regardless, this would allow two different Swift authors to create new custom access groups with the same name but completely different semantics.</div><div><br></div><div>The biggest problem, though, is that you can no longer look at a type/member in relative isolation and see where it's accessible from. "public", "internal", and so forth all have well-defined simple meanings. This change would mean that any time I look at a type/member with a custom access group, I have to go fishing for the group's declaration in order to understand who does and doesn't have access to it.</div><div><br></div><div>IMO, programmers simply do not need to finely tune and audit the visibility of their code to this level of detail. For public API boundaries, you should absolutely be able to control things. But once you're within a module or within a file—code that 99% of the time you as a developer or development team have complete control over—the value of being able to protect yourself from yourself or other teammates drops *significantly*. I argued this about scoped private as well, but the core team felt that it had legitimate enough use by a large enough number of people. On the other hand, I can't imagine that this would hold its weight in terms of value-added vs. implementation complexity and difficulty it would add to making the language readable and learnable.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 14, 2017 at 2:01 PM Erica Sadun 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">Pull request: <a href="https://github.com/apple/swift-evolution/pull/681" target="_blank">https://github.com/apple/swift-evolution/pull/681</a><div><br></div><div>Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.</div><div><br></div><div>We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled. </div><div><br></div><div>Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.</div><div><br></div><div>Thank you in advance for your feedback,</div><div><br></div><div>-- Erica</div><div><br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</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>