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

[Jakub Suder]

> What is your evaluation of the proposal?

If this is the last option we have to change the status quo, any renaming
is off the table, no further changes after Swift 4, and it's either this or
being stuck with 'fileprivate' until the end of time, then +1 from me. It
will increase the convenience of access control for people like me who see
types and their extensions as parts of the same entity, just spread
visually across neighboring blocks. In almost any other language these two
would indeed be one entity, since most languages don't have any way of
dividing types into pieces this way.

However, IMHO any of these would be a better solution:

1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate'
back to 'private'

2) Rename 'fileprivate' to something more friendly (I liked the 'local'
suggestion that Vladimir made today)

3) Postpone this until we add submodules, but with the assumption that it
will be possible to make some source-breaking changes at that point

The thing I don't like about this proposal (or status quo) - apart from the
fact that it will make people who like the current strict private unhappy -
is that 'private' even right now means kind of two different things:

- for a property or a method defined in a class/struct, it means "available
only inside this type"
- for a private global variable/constant/function, or a private type or
extension, it means "available in this file" i.e. the same as 'fileprivate'

So if we're worried that this proposal makes the meaning of 'private'
unclear - it already is unclear. Wouldn't it be much more clear if private
global variables, functions and classes were required to use the access
level that means "available in this file", since that's how they actually
work? (as long as this level is not named 'fileprivate' :)

And the other access level, the "available only inside this type" (private
/ scoped), could only be used for things that are actually contained inside
a type, and wouldn't have two different meanings depending on whether it's
at the root of the file or nested inside something else.

I really believe that even though this is kind of painful for everyone,
it's worth spending time to figure out a solution that satisfies most of us
and makes the language clearer and friendlier in the long term, even if it
means breaking compatibility again. Do we want to be stuck with an
imperfect solution 10 years from now, because we didn't want to do this
last breaking change now?


> Is the problem being addressed significant enough to warrant a change to
Swift?

I think almost everyone here agrees it is significant.


> Does this proposal fit well with the feel and direction of Swift?

This is a difficult question. IMHO it would definitely fit much better with
the direction of Swift if we bit the bullet and did whatever we agree will
make the language simpler and better long term, regardless how many changed
lines in git this will cause when Swift 4 is released.


> If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I've used many languages, but I think in none of them it was a common thing
(or even a possibility) to split types into several blocks like we do in
Swift with extensions, so the main issue we're talking about didn't exist
there. In Ruby you can kind of do the same thing with modules - if you have
a private method in a module, you can access it from methods in the main
type, even if they're defined in a different file. (But Ruby isn't very
strict about access control in general, e.g. it allows you to call private
methods on any object via #send).


> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I've read or skimmed through most of the messages in the recent threads
about this and the last proposal.

Disclaimer: I have very little experience with Swift 3 (but plenty with
Swift 2.x).

Kuba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170408/c764c33b/attachment.html>