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

[Daniel Leping]

Gonçalo, I can suggest a bit different API to avoid clashing. Something
like:

private (file, set)

Instead of:

private (file) (set)

Looks easier to me as it poses a possibility just to list the attributes in
a pretty much standard way.

On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swift-evolution <
swift-evolution at swift.org> wrote:

> *@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
> _______________________________________________
> 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/20161201/0821aa17/attachment.html>