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

[Ilya Belenkiy]

The main argument against seems to be that using “scoped” doesn’t allow
putting more code in extensions inside the same file. And the reason to put
code into extensions is to group it in some meaningful way, the most common
being implementation of a protocol. I completely agree that this is a nice
feature, and I wouldn’t want to lose it myself. At the same time, I think
that the most important grouping is one that is based on whether something
needs access to internal state and can potentially break it. My reasoning:

- the compiler can help ensure correctness because it won’t let you use
unsafe APIs that could break invariants / internal state.

- changing the implementation is much easier because implementation details
are not scattered throughout the file and are isolated in one place (the
scope).

- the tools can (and should) hide the “scoped” elements from the outside
and make code completion for the rest of the code much more convenient

But the more general question is this: are you willing to give up on
compiler's help with code correctness for a little more code grouping
convenience? This same argument could be made about “private”. Let’s say
you have a very large file that you want to break into smaller files, and
the code uses “private” throughout the file. If you break it up, you have
to remove “private” and make it “internal” and lose the compiler’s’ help
with access control. If we go that route, only “public” vs “internal” makes
sense. And yet, “private” is there. As it is today, it’s a good alternative
to “friend” in C++, but it doesn’t address the problem that “scoped” solves.

On Fri, Mar 4, 2016 at 4:12 AM Adrian Kashivskyy via swift-evolution <
swift-evolution at swift.org> wrote:

> Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes and no. Yes, because it a
>
>
> Sorry, I forgot to finish the sentence. 🙈
>
> Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes and no. Yes, because it could in some small percent increase the
> safety of our programs. No, because it would strip away the "composability"
> of our code.
>
>
> Pozdrawiam – Regards,
> Adrian Kashivskyy
>
> Wiadomość napisana przez Adrian Kashivskyy via swift-evolution <
> swift-evolution at swift.org> w dniu 04.03.2016, o godz. 10:09:
>
>
> What is your evaluation of the proposal?
>
>
> Neutral. While I agree that scoped access levels can be useful in some
> cases, I don't see much long-term profits, especially when using a
> "protocol conformance in an extension" style:
>
> struct Foo {
> private func doSomethingInternal()
> }
>
> extension Foo: Barable {
> func bar() {
> doSomethingInternal()
> }
> }
>
> The above would not be possible to achieve with scoped access levels.
>
> Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> I don't think so. File access level does the job well for me.
>
> Does this proposal fit well with the feel and direction of Swift?
>
>
> Yes and no. Yes, because it a
>
> If you have used other languages or libraries with a similar feature, how
> do you feel that this proposal compares to those?
>
>
> Yes, Ruby, PHP, C++. In those languages, there are no file access levels
> and so the scoped access levels are the only ones which allow to hide the
> implementation details from the outside world. In Swift, however, file
> access level allows us to do the same with additional bonus – we can use
> those `private` members in extensions.
>
> How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
>
> Pozdrawiam – Regards,
> Adrian Kashivskyy
>
> Wiadomość napisana przez Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> w dniu 26.02.2016, o godz. 20:05:
>
> Hello Swift community,
>
> The review of SE-0025 “Scoped Access Level" begins now and runs through
> March 3, 2016. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
>
> Reply text
>
> Other replies
>
> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>    - What is your evaluation of the proposal?
>    - Is the problem being addressed significant enough to warrant a
>    change to Swift?
>    - Does this proposal fit well with the feel and direction of Swift?
>    - If you have used other languages or libraries with a similar
>    feature, how do you feel that this proposal compares to those?
>    - How much effort did you put into your review? A glance, a quick
>    reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug Gregor
>
> Review Manager
> _______________________________________________
> 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
>
> _______________________________________________
> 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/20160304/9442685d/attachment.html>