[swift-evolution] [swift-evolution-announce] [Review] SE-0025 Scoped Access Level

[Ilya Belenkiy]

> Swift's access modifier control is about code unit access levels. This
proposal breaks this conceptual model. Now instead of thinking of publicly
exposed APIs, APIs using only within the context of the module, and APIs
local to the file, I now need to parse semantic scopes to understand where
a piece of code can be used.

> Basically Swift's model is:
  - public exports
  - internal exports
  - no exports

> This proposal doesn't fit anywhere in that model.

This is one interoperation. Here is another that makes it fit perfectly
well:

- public: exports symbol to all files
- internal: exports symbol to module files
- private: exports symbol to one file containing the scope
- scoped: no export

> Yes, this basically what private is other languages. However,
traditionally "private scope" implementations have severe weaknesses in the
ability to expose the implementation details only to helper code within the
same file. Creating local re-invents part of that.

Yes, and "private" is great for that. We can have both. They serve
different purposes.

On Mon, Feb 29, 2016 at 12:31 PM David Owens II via swift-evolution <
swift-evolution at swift.org> wrote:

>
> *What is your evaluation of the proposal?*
>
> -1. I disagree with the starting motivation points, so it's hard to really
> see the value in the rest of the arguments.
>
>
> *Is the problem being addressed significant enough to warrant a change to
> Swift?*
>
> No.
>
>
> *Does this proposal fit well with the feel and direction of Swift?*
>
> No. Swift's access modifier control is about code unit access levels. This
> proposal breaks this conceptual model. Now instead of thinking of publicly
> exposed APIs, APIs using only within the context of the module, and APIs
> local to the file, I now need to parse semantic scopes to understand where
> a piece of code can be used.
>
> Basically Swift's model is:
>   - public exports
>   - internal exports
>   - no exports
>
> This proposal doesn't fit anywhere in that model.
>
>
> *If you have used other languages or libraries with a similar feature, how
> do you feel that this proposal compares to those?*
>
> Yes, this basically what private is other languages. However,
> traditionally "private scope" implementations have severe weaknesses in the
> ability to expose the implementation details only to helper code within the
> same file. Creating local re-invents part of that.
>
> *How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?*
>
> I've read the review and followed much of the conversation, including
> participating in the previous thread on this topic.
> _______________________________________________
> 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/20160301/321dc08c/attachment.html>