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

[Xiaodi Wu]

This discussion has been had on this list several times already. Using a
name other than fileprivate, in particular, was part of the original
discussion and the core team selected the current spelling.

As Tino mentioned, submodules are a topic that the community has already
expressed some interest in incorporating in the future and is listed as a
possible topic by the core team for Swift 4 stage 2. At that time, it would
seem obvious that submodule access levels would be introduced. It seems
that this idea would be largely duplicative of that functionality, and it
would destroy the current deliberately chosen file-based design for access
levels.

On Thu, Dec 1, 2016 at 08:42 João David via swift-evolution <
swift-evolution at swift.org> wrote:

> @Daniel, agree.
>
>
> Sent from my iPhone. Erroneous words are a feature, not a typo.
>
> On 1 Dec 2016, at 14:23, Daniel Leping <daniel at crossroadlabs.xyz> wrote:
>
> 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
>
> _______________________________________________
> 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/9ce7cfbc/attachment.html>