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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to