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

[Daniel Leping]

How about making things more organized and move to syntax like this:

private(scope) decl

Where scope is optional and defaults to full private. Can take "file" and
"type" values. I.e:

private (file) var i = 1
private func a()
private (type) func b()

This way we can have a very fine grained access levels and maintain a
better structure. Who knows maybe in Swift 5 there will be need for more.

On Thu, 1 Dec 2016 at 12:08 Álvaro Monteiro via swift-evolution <
swift-evolution at swift.org> wrote:

> I think the idea behind this proposal is quite the contrary. It is about
> conveying the right message through the use of an expressive access control
> that addresses common use cases and leaves behind fileprivate which IMHO is
> a C inherited way of thinking.
>
> Let me try to be clear:
>
> - Private would work the same way as it does now: it would not be
> accessible through an extension.
> - Typeprivate would be accessible through an extension inside the module.
> - Typeprivate would allow to abandon the odd fileprivate. Access level
> would be constrained to swift constructs (structs, classes and extensions)
> and not to a compiler artifact (file).
> - Typeprivate would allow to address a very common use case: separate
> concerns of a swift struct/class through extensions and at the same time
> allow accessing private properties within this class/struct. At the moment
> you would have to have everything in the same file (and leverage
> fileprivate) or use internal and let it be accessible across the module.
> One good argument in favor of internal in these use cases would be that a
> given module should only be worried about what it exposes to consumers
> (public) and internally it's only a concern to the developers ("producers")
> of the module. I disagree with this because communication is one of the
> core tenets of swift and stating a property is internal just because is
> declared in another file is bizarre, unswift, error prone and it surely
> does not convey the right message the developer wants.
>
> On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> It also means that anybody who want to access your private var will just
> have to write an extension to expose it.
>
> imho this is wrong thinking:
> Access control is no tool to offer real "protection" — it can't stop
> someone who wants to break a system.
> Especially in the world of open source, it is merely an advice from the
> author not to do certain things.
>
> _______________________________________________
> 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/bd7917cb/attachment.html>