[swift-evolution] final + lazy + fileprivate modifiers

[Matthew Johnson]

Sent from my iPad

> On Feb 17, 2017, at 4:51 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Although there was willingness to depart from conventions in other C-style languages, I believe it was decided that having a counterpart to other languages' "private" that isn't named private *and* also a "private" that isn't a counterpart to other languages' "private" was too idiosyncratic and actively confusing.

Ahh, yes.  I remember this being discussed.  I think that we have learned a lot since this discussion took place.  I think it puts too much weight on what other languages do and not enough on what is right for Swift where extensions are used pervasively to organize code.  

The worst case scenario for someone coming from a C-style language who doesn't understand the nuances of Swift yet is that they use `private` and the entity has broader visibility than expected, but still within the same file.  Given the volume of support for the argument that access control within the same file isn't important I think it's safe to say that the consequences of this misunderstanding are not that big a deal.  If the developer cares about such things they will learn about `scoped` soon enough.

> 
> If I recall, the proposal as submitted for core team review actually proposed something like you suggest, and it was the core team that decided to change it on review.

Yes, it didn't touch `private` and used `local` for scoped access which was a bad name for many reasons.  The conversation had always called it "scoped access" informally.  I think `scoped` would make a good name for it and find it pretty unfortunate that it wasn't spelled that way in the initial proposal. 

> 
> 
>> On Fri, Feb 17, 2017 at 16:36 Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> > On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> >
>> >> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
>> >>
>> >> Personally I feel enforced encapsulation of implementation detail to the latter group is less important than the former, and can be handled by convention. Whereas other users of your module definitely benefit from access control and being able to consume a clearly-defined interface.
>> >
>> > I think failing to provide some sort of below-`internal` privacy would be missing *really* low-hanging fruit for no good reason. The languages I can think of which don't include some sort of sub-library-wide privacy level—Objective-C, Javascript, Perl, Python—usually have very simple object designs with a flat namespace. (Well, there's Rust, but Rust lets you wrap anything you'd like in a module.) Even Objective-C in practice includes a `fileprivate` equivalent in the form of methods declared only in the .m file.
>> >
>> > I also think it's often helpful to be able to change a member's access level without having to change all references to it. Publishing or privatizing an interface is not an uncommon refactoring.
>> >
>> > Not everybody likes our current semantics, but that's no reason to throw the feature out entirely.
>> 
>> +1.  I’d like to see `private` revert to the Swift 2 meaning, and hopefully we can reconsider using `scoped` as the keyword for scoped access rather than abandoning it.  Does anyone remember why this was considered a bad idea?
>> 
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/92ad54e8/attachment.html>