On Fri, Apr 7, 2017 at 1:10 AM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:
Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md > - What is your evaluation of the proposal? > > Strongly +1, this is definitely a strong step in a good direction, and it would make Swift more pleasant to work with for the programmers that use extensions to organize their code. As I see it by reading the strong opinions about this proposal in the mailing list, we can split the affected groups into three: 1. Programmers that do not use extensions in the same file to organize their code. 2. Programmers that use extensions to organize their code but do not care about sharing implementation details in the same file within a type. 3. Programmers that use extensions to organize their code but care about sharing implementation details in the same file within a type. The first bunch is not affected at all by this proposal, no matter the programmer style that they choose (like spliting extensions in separate files). They may feel that nothing improves with this, or that some opportunity is missed by this, or that SE-0025 <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md> will never be reverted if this proposal gets accepted. Nevertheless, this change do not affect their code at all, even if it pushes the community to other programming style. The second bunch, were I live, will receive this change with open arms. We think that if you are writing in a file you have access to the code in that file and can see/modify all the usages. It may be too little for some, but this proposal clearly improves the current situation for this group. The third bunch are the ones whose code can be hurt, that is clear and I'm not going to judge their reasons here. I suppose that this group was very much in favor of the divisive SE-0025 <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>. But I'm not seeing this group happy with any proposal that does not includes more granularity, like another scope modifier, and any such proposal will hurt the first and second groups. I don't know how big or representatives are these groups, I suppose the first group will include the majority of newcomers and the second group will include more seasoned Cocoa programmers, but that is just my impression. Also, I like this change very much because the Swift 4 migration will be painlessly for basically everyone, unlike the Swift 3 fileprivate migration. No code should be changed if you don't want it, and the code will keep working the same. The only case where you can have problems migrating would be if you had: struct House { private func openWindows() {} } extension House { private func openWindows() {} } But that is not even accepted by the compiler right now (at least not in the Linux one). > - Is the problem being addressed significant enough to warrant a > change to Swift? > > Yes. This would be the thing that would rush me to upgrade to Swift 4 as fast as possible, since it would remove the single major painpoint that I had with Swift syntax. > - Does this proposal fit well with the feel and direction of Swift? > > Yes, it encourages again the use of extensions, not that it needed to. > - If you have used other languages or libraries with a similar > feature, how do you feel that this proposal compares to those? > > Not applicable, I think. > - How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > Daily experience working with fileprivate in Swift since the first beta of Swift 3. -- INNOVATION IN PERSONAL COMMS *[image: Imágenes integradas 5]* *Víctor Pimentel Rodríguez · *Principal iOS Engineer vpimen...@tuenti.com +34 914 294 039 <javascript:void(0);> — +34 687 840 886 <javascript:void(0);> C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid Tuenti Technologies, S.L. www.tu.com www.tuenti.com
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution