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 > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> wrote: > Hi Erica, > > > On 15 Apr 2017, at 08:44, Erica Sadun via swift-evolution > > <[email protected] <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
