[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Víctor Pimentel Rodríguez vpimentel at tuenti.com
Fri Apr 7 03:12:42 CDT 2017

On Fri, Apr 7, 2017 at 1:10 AM Douglas Gregor via swift-evolution <
swift-evolution at swift.org> wrote:

Proposal link:

>    - 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
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
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

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.



*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimentel at tuenti.com

+34 914 294 039 <javascript:void(0);> — +34 687 840 886
C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid
Tuenti Technologies, S.L.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170407/ccbd6004/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Transition_Logo_172.png
Type: image/png
Size: 6074 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170407/ccbd6004/attachment.png>

More information about the swift-evolution mailing list