Just to double check: do I need to do anything with the proposal? It sounds like it was decided, and Doug will update the proposal, but I 'd like to make sure that there is nothing to be done on my end.
On Fri, Apr 1, 2016 at 5:07 PM Ilya Belenkiy <[email protected]> wrote: > Great! Glad that we have a decision. > > On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution < > [email protected]> wrote: > >> On Mar 30, 2016, at 9:22 PM, Chris Lattner <[email protected]> wrote: >> > >> > I’ve seen a number of concerns on this list about moduleprivate, and >> how it penalizes folks who want to explicitly write their access control. >> I’ve come to think that there is yes-another possible path forward here >> (which I haven’t seen mentioned so far): >> > >> > public >> > internal >> > fileprivate >> > private >> >> Hi Everyone, >> >> Thank you for all of the input. I know that this was a highly >> contentious topic, that it is impossible to make everyone happy. Getting >> the different inputs and perspectives has been very very useful. >> >> The core team met to discuss this, and settled on the list above: >> public/internal/fileprivate/private. This preserves the benefit of the >> “fileprivate” concept that we have today in Swift, while aligning the >> “private” keyword with common expectations of people coming to Swift. This >> also makes “private" the "safe default” for cases where you don’t think >> about which one you want to use, and this schema will cause minimal churn >> for existing Swift code. >> >> Thank you again for all of the input and discussion! >> >> -Chris >> >> btw, to be clear, this is *not* an April 1 joke. >> _______________________________________________ >> 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
