<div dir="ltr">Great! Glad that we have a decision.<div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mar 30, 2016, at 9:22 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br>
><br>
> 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):<br>
><br>
> public<br>
> internal<br>
> fileprivate<br>
> private<br>
<br>
Hi Everyone,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thank you again for all of the input and discussion!<br>
<br>
-Chris<br>
<br>
btw, to be clear, this is *not* an April 1 joke.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>