[swift-evolution] Type-based ‘private’ access within a file

David Hart david at hartbit.com
Mon Apr 3 15:10:05 CDT 2017


> On 3 Apr 2017, at 22:01, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> I'm disappointed in this turn of events. While I thought that accepting SE-0159 would have been a better outcome than rejecting it, I am certain that this is an inferior choice to both of those outcomes.
> 
> The key problem isn't principally _what_ this proposed private is. It is that, if adopted, this would be the third flavor of private in as many years. It is a new design with its own kinks (what to do about `private extension`, for example?) and the resultant churn would be most unfortunate.

I agree it is not ideal. But I’ll take it over the current status-quo where we are continually hoping between private and fileprivate without a good default.

> On Mon, Apr 3, 2017 at 14:50 David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> The problem I see with that is that it would introduce orthogonal access levels whereas they have all been hierarchal in nature up to now.
> 
>> On 3 Apr 2017, at 21:36, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> 
>>> On Apr 3, 2017, at 2:28 PM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Btw, I know what I'm going to propose is a bit crazy, but how about making private visible to extensions even outside the file but in the same module?
>> 
>> That’s actually what I suggested in my original post on the topic. My feeling was that it would allow breaking a particularly large type into separate files, thus alleviating the “huge file” problem that Swift has (and which Charlie Monroe brought up as a concern).
>> 
>> It’s still what I’d prefer personally, although I can understand why the core team might want to restrict it to files.
>> 
>> Charles
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170403/15c99afd/attachment.html>


More information about the swift-evolution mailing list