> On Feb 19, 2017, at 7:29 PM, David Waite <[email protected]> wrote:
>
> Swift 2’s access modifiers had a very simple ‘elevator pitch’ -
> “If you are writing code, by default everything within the module (app or
> library) your are working in can see it, but other modules cannot. If you
> want other modules to see features of your module, you make them public. If
> something is an implementation detail that even other parts of your module
> shouldn’t mess with, you make them private”
>
> I think I would have trouble *just* describing private vs file private in
> that amount of space. One sign of the complexity was that even after a
> ridiculous amount of bike shedding, we couldn’t come up with better way to
> distinguish the two than to call one “fileprivate”. So I would say for the
> purposes of swift as a language suitable for learning, the change was
> harmful.
Swift’s scope private is not different than other languages.
>
> Secondly, there are reasons to choose one versus the other, but the
> combination of the meaning of the keyword changing between swift 2 and 3 and
> the spelling of “fileprivate” means that the choice of one or the other
> doesn’t really communicate anything to a developer of a typical project - it
> appears to often be a matter of the legacy of the code as well as developer
> taste. That the choice between private and file private doesn’t illustrate
> intent is harmful to coordination.
This really depends on where private is. If it on the top scope then private is
the same as file-private and your statement is correct.
SE-0025 was changed to allow higher access modifier for inner types and this is
when things started to get confusing because the vast majority of times when
scope private was being used in reality is the same as fileprivate. The fact
that we encourage the use of scope private over file-private is harmful because
of the confusion.
// File.swift
private let myString = "" // fileprivate same as private
fileprivate let myString2 = "" // fileprivate same as private
private struct MyType { // fileprivate same as private
fileprivate struct MyInnerType{ // private never the same as private
fileprivate struct MyInnerType{} // private never the same as private
}
}
// end of File.swift
>
> A third point (which is a bit more complex/convoluted) is that fileprivate
> remained an essential language feature because it allows implementation in
> extensions, and allows a simple “friend”-like feature where types that need
> access to implementation details due to higher coupling could be bundled into
> the same file. Outside of a desire of a scoped ‘private’ simply to match the
> behavior of certain other languages, private is used to hide implementation
> details from other parts of a file, while file private exposes them within
> the file.
>
> There is a potential that file-private can lead to an explosion of complexity
> due to a large amount of “friendly types” being bundled into the same file.
> In that sense, ‘private’ was wrong because it was adding complexity at the
> file level, when really a new access level would possibly have been more
> productive to define at the at the small-group-of-files level - either via a
> friend access level or submodules. We still have the potential of
> unmanageable files due to friend types, but any additional access levels to
> aid with this problem would have to be weighed against a now significantly
> more complex access model including file and scoped private. In that sense,
> the inclusion of scoped private may indeed be harmful in that it increases
> the challenge of much more useful access levels being added to the language.
>
> -DW
>
>> On Feb 18, 2017, at 11:57 PM, Jose Cheyo Jimenez via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> How exactly is the use of scope private harmful?
>>
>> Do you have specific examples when scope private was harmful?
>>
>>
>>
>>> On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez via swift-evolution
>>> wrote:
>>>> I don’t think there is evidence that scope private in Swift3 is "actively
>>>> harmful”.
>>>>
>>>
>>> This thread would quite simply not exist if not to present exactly that
>>> evidence. It exists; we, the change's detractors, exist.
>>>
>>> Zachary
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
