[swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

[Dave DeLong]

While I appreciate the simplicity of such a statement, in reality it would be a step backward even from Objective-C and is not a practical design for anyone who works on a multi-person team. In Objective-C, members are selectively #import’d, so everything is “private” unless it’s #import’d. Since Swift takes the approach of implicit importation of the module, there’s no way to hide parts of functionality from other subsystems in your module without resorting to fragile and unsafe naming conventions (e.g.: “don’t use things that start with an underscore”). It would be a massive design mistake, for example, for every private method on every piece of code in UIKit to be exposed to every other client inside UIKit.

Dave

> On Apr 14, 2017, at 9:31 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> If we're to talk about ideas and needs, my favored access control design is one that pares back to only two modifiers: public and internal. Either the thing is public API, or it is not. Ditch everything else.
> On Fri, Apr 14, 2017 at 19:42 Tony Arnold via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Hi Erica,
> 
> > On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > Like SE-0077's precedencegroup, this proposal is meant to mostly be invisible to end-users. Most Swift users will never know anything changed from S3/SE-0169 but it would support powerful use-cases for people who do serious coding.
> 
> I really like this proposal (Flexible Scoping). My one suggestion would be to make it clearer that for the average user, they just keep using the pre-defined access control levels as you’ve mentioned above.
> 
> I’m a little tired of seeing flexible access control referred to as an anti-goal — everyone has different requirements from this language, and this is the first time I’ve seen something that would potentially cover everybody’s needs without needlessly restricting things to meet one group’s idea of best practice. I’d ask that members of the community please consider that their ideas and needs are not everybody’s ideas and needs when assessing potentially contentious proposals like this one.
> 
> Personally, I’ve found the conversations around access control on this mailing list draining to the point I’ve unsubscribed from the list a few times. This is the first time I've felt like someone might be on the right track to solving this issue in a future-proof manner, and not just whacking a band-aid on the actual underlying issues.
> 
> Regardless of the outcome of discussions around this, thank you for the work that Jeffrey and yourself have put into it.
> 
> I'll +1 the heck out of this proposal if it gets to review.
> 
> thanks,
> 
> 
> Tony
> 
> 
> 
> 
> ----------
> Tony Arnold
> +61 411 268 532
> http://thecocoabots.com/ <http://thecocoabots.com/>
> 
> ABN: 14831833541
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/638dd0f9/attachment.html>