Maybe the burden of proof required for this change is not met even though it frustrates those who dislike fileprivate. I honestly think our energies are better spent on other parts of the language than arguing on this... unless the discussion has time to grow into a proper holistic manifesto on access controls and goes beyond the current "let's just kill fileprivate and make private behave like it".
The current private provides useful functionality for a way of composing and designing objects... fileprivate is four more characters and most of us use autocompletion features on modern IDE's now, does what it says on the tin, provides no issue to newcomers really, and it is not clear to me we have a better alternative... we all adopted this current approach for a reason, the core team did not trip into it. Also, do we have data about this being an issue? For an opinionated language and opinionated audience, this is a bit OT and we should discuss it in a different thread, we should be gathering data and help it drive our opinions (to back claims about better stability, higher performance, etc...). Sent from my iPhone > On 19 Feb 2017, at 23:52, Tony Arnold via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On 20 Feb 2017, at 06:25, Jose Cheyo Jimenez via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> We need more examples to make this case. > > How do we provide those examples? This thread has been actively discussed for > close to a week now, so it would be good to do something concrete about it. I > think Chris’ second suggestion fits my idea of a reasonable “Default” level > of privacy when starting out, and fits the model of progressive disclosure as > you so excellently pointed out. > > Is this something that should go through a proper Proposal? Is someone doing > this already? I’d like to help/contribute if it is. > > thanks, > > > Tony > > > > ---------- > Tony Arnold > +61 411 268 532 > http://thecocoabots.com/ > > ABN: 14831833541 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
