[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Gonçalo Alvarez Peixoto]

*@Daniel*
I am very fond of your idea, as I believe it add extra flexibility to this
solution, as Álvaro mentioned. My only concern is somehow related to
semantics.
Should we add the extra scope detail as you suggest, then it could clash
with the current way of setting a setter as private or fileprivate:

Current:
fileprivate(set)

Suggested:
private(file)(set)

Still, of all the hurdles one might face, this one I believe is definitely
the one that poses the less threat!

*@Tino*
As you imply on a previous email, this solution might even facilitate the
introduction of new levels of access control all throughout modules,
whether internally and externally. While I do agree complexity does raise
an issue in designing a fine solution for access control, I insist this
concern should not block the language's evolution into finer grained
control and better focused levels of scope. Quoting Álvaro:  "communication
is something that everyone agrees is a essential in swift and access
control is one of the many ways developers have to properly describe (and
communicate) an API."

Also Tino, you state:
"The question for me is how much complexity should be accepted as a
tradeoff for increased expressiveness?
"private, internal, public" was quite simple, but the current system is
already quite complicated, and it doesn't scale well."

In fact, I consider this change a great opportunity for the current system
to be revisited in a gradual manner.
As to the equatable issue you pointed out, is there a reason why replacing
the fileprivate access control level by with a typeprivate would not solve
the problem raised with private?

There's yet another issue I would like to reinforce, one raised on previous
emails. As stated before, I do believe fileprivate, as a compiler related
construct, opens the door for one to access members from another member, as
long as they'r all sitting within the same file. This creates conditions
for a odd and dangerous pattern. While I don't think fileprivate aims at
promoting several type implementation within the same file, it certainly
opens that door. That's one pattern a typeprivate access control level
would grant no advantages in using.

Best,
Gonçalo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161201/a2236592/attachment.html>