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 <ilya.belenkiy@gmail.com> wrote:
Great! Glad that we have a decision.
On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
On Mar 30, 2016, at 9:22 PM, Chris Lattner <clattner@apple.com> 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
> privateHi 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution