[Review] SE-0159: Fix Private Access Levels

Vinnie_Hesener · March 24, 2017, 10:27am

This discussion escalated real quickly. There are some very bright minds in
the mud right now, but I think there may still be a way to salvage this
discussion.

Chris talked about there being two layers to Swift... the easy mode for
adoption and outreach, then the advanced mode for taking over the world.
This requires a delicate balance of features vs usability (e.g. MS Paint vs
Photoshop). There are various ways to approach that balance, but they
almost always require creativity and cooperation from the smartest guys in
the room.

I'm not one of those guys, but let me throw out some food for thought. Is
there a way to not only please both generalized arguments, but also solve
the root of the problem? For instance, has anyone thought about why we even
call things public, private, etc? Other than their initial meaning, the
answer may be "other languages do it" or even better "that is what prevents
confusion and dupe questions on stackoverflow". Fair enough.

I realize this would be jolting for most, but would anyone be asking the
stackoverflow ether what a **scope** var was? How about a **file** func?
How about a SO title: "What does **module** let myVar refer to?"

Don't we have the opportunity to offer, within reason, a large set of
accessors that are self explanatory? I think it may solve the complexity
for usefulness exchange because they are simply there for the advanced
users that want to use them. There's no choosing for newbs because the
choice is in the name, assuming we name them pristinely (I have faith!).

I'm also a little cooky too, but maybe this can spark some creativity in a
more wholistic solution for both sides.

Hello Swift community,

The review of SE-0159 "Fix Private Access Levels" begins now and runs

through March 27, 2017. The proposal is available here:

github.com

apple/swift-evolution/blob/main/proposals/0159-fix-private-access-levels.md

# Fix Private Access Levels

* Proposal: [SE-0159](0159-fix-private-access-levels.md)
* Author: [David Hart](http://github.com/hartbit)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Rejected**
* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0159-fix-private-access-levels/5576)

## Introduction

This proposal presents the problems that came with the the access level modifications in [SE-0025](https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md) and proposes reverting to Swift 2 behaviour.

## Motivation

Since the release of Swift 3, the access level change of SE-0025 was met with dissatisfaction by a substantial proportion of the general Swift community. Those changes can be viewed as *actively harmful*, the new requirement for syntax/API changes.

The `private` keyword is a "soft default" access modifier for restricting access within a file. Scoped access is not a good behavior for a "soft default" because it is extremely common to use several extensions within a file. A "soft default" (and therefore `private`) should work well with this idiom. It is fair to say that changing the behavior of `private` such that it does not work well with extensions meets the criteria of actively harmful in the sense that it subtly encourages overuse of scoped access control and discourages the more reasonable default by giving it the awkward name `fileprivate`.

Compared to a file-based access level, the scoped-based access level adds meaningful information by hiding implementation details which do not concern other types or extensions in the same file. But is that distinction between `private` and `fileprivate` actively used by the larger community of Swift developers? And if it were used pervasively, would it be worth the cognitive load and complexity of keeping two very similar access levels in the language? This proposal argues that answer to both questions is no and therefore wish to simplify Swift's access control story by removing scoped access and leaving more design breathing space for future discussions around submodules.

This file has been truncated. show original

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<

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:

github.com

apple/swift-evolution/blob/main/proposals/0159-fix-private-access-levels.md

# Fix Private Access Levels

* Proposal: [SE-0159](0159-fix-private-access-levels.md)
* Author: [David Hart](http://github.com/hartbit)
* Review Manager: [Doug Gregor](https://github.com/DougGregor)
* Status: **Rejected**
* Decision Notes: [Rationale](https://forums.swift.org/t/rejected-se-0159-fix-private-access-levels/5576)

## Introduction

This proposal presents the problems that came with the the access level modifications in [SE-0025](https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md) and proposes reverting to Swift 2 behaviour.

## Motivation

Since the release of Swift 3, the access level change of SE-0025 was met with dissatisfaction by a substantial proportion of the general Swift community. Those changes can be viewed as *actively harmful*, the new requirement for syntax/API changes.

The `private` keyword is a "soft default" access modifier for restricting access within a file. Scoped access is not a good behavior for a "soft default" because it is extremely common to use several extensions within a file. A "soft default" (and therefore `private`) should work well with this idiom. It is fair to say that changing the behavior of `private` such that it does not work well with extensions meets the criteria of actively harmful in the sense that it subtly encourages overuse of scoped access control and discourages the more reasonable default by giving it the awkward name `fileprivate`.

Compared to a file-based access level, the scoped-based access level adds meaningful information by hiding implementation details which do not concern other types or extensions in the same file. But is that distinction between `private` and `fileprivate` actively used by the larger community of Swift developers? And if it were used pervasively, would it be worth the cognitive load and complexity of keeping two very similar access levels in the language? This proposal argues that answer to both questions is no and therefore wish to simplify Swift's access control story by removing scoped access and leaving more design breathing space for future discussions around submodules.

This file has been truncated. show original

Reply text
Other replies
<

github.com

apple/swift-evolution/blob/main/process.md#what-goes-into-a-review-1>What

# Swift Evolution Process

Swift is a powerful and intuitive programming language that is designed to make writing and maintaining correct programs easier. Swift is growing and evolving, guided by a community-driven process referred to as the Swift evolution process, maintained by the [Language Steering Group][language-steering-group]. This document outlines the Swift evolution process and how a feature grows from a rough idea into something that can improve the Swift development experience for millions of programmers.

## Scope

The Swift evolution process covers all design changes, no matter how small, to the Swift language, its standard library, and the core tools necessary to build Swift programs.  This includes additions, removals, and changes to:
- the features of the Swift language,
- the public interface of the Swift standard library,
- the configuration of the Swift compiler, and
- the core tools of the Swift package ecosystem, including the configuration of the [Swift package manager](https://www.swift.org/package-manager/) and the design of its manifest files.

The design of other tools, such as IDEs, debuggers, and documentation generators, is not covered by the evolution process.  The Core Team may create workgroups to guide and make recommendations about the development of these tools, but the output of those workgroups is not reviewed.

The evolution process does not cover experimental features, which can be added, changed, or removed at any time.  Implementors should take steps to prevent the accidental use of experimental features, such as by enabling them only under explicitly experimental options.  Features should not be allowed to remain perpetually experimental; a feature with no clear path for development into an official feature should be removed.

Changes such as bug fixes, optimizations, or diagnostic improvements can be contributed via the normal contribution process; see [Contributing to Swift](https://www.swift.org/contributing/).  Some bug fixes are effectively substantial changes to the design, even if they're just making the implementation match the official documentation; whether such a change requires evolution review is up to the appropriate evolution workgroup.

Which parts of the Swift project are covered by the evolution process is ultimately up to the judgment of the Core Team.

This file has been truncated. show original

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<

https://github.com/apple/swift-evolution/blob/master/process.md>

···

Thank you,

-Doug

Review Manager

xwu · March 24, 2017, 11:11am

`scoped` was the name originally proposed in SE-0025, changed by the core
team on acceptance to `private`, and `file` was one of the suggestions for
what used to be called `private`; I remember because I suggested it too; it
was renamed to `fileprivate` after consideration of this alternative.

···

On Fri, Mar 24, 2017 at 5:27 AM, Vinnie Hesener via swift-evolution < swift-evolution@swift.org> wrote:

This discussion escalated real quickly. There are some very bright minds
in the mud right now, but I think there may still be a way to salvage this
discussion.

Chris talked about there being two layers to Swift... the easy mode for
adoption and outreach, then the advanced mode for taking over the world.
This requires a delicate balance of features vs usability (e.g. MS Paint vs
Photoshop). There are various ways to approach that balance, but they
almost always require creativity and cooperation from the smartest guys in
the room.

I'm not one of those guys, but let me throw out some food for thought. Is
there a way to not only please both generalized arguments, but also solve
the root of the problem? For instance, has anyone thought about why we even
call things public, private, etc? Other than their initial meaning, the
answer may be "other languages do it" or even better "that is what prevents
confusion and dupe questions on stackoverflow". Fair enough.

I realize this would be jolting for most, but would anyone be asking the
stackoverflow ether what a **scope** var was? How about a **file** func?
How about a SO title: "What does **module** let myVar refer to?"

Don't we have the opportunity to offer, within reason, a large set of
accessors that are self explanatory? I think it may solve the complexity
for usefulness exchange because they are simply there for the advanced
users that want to use them. There's no choosing for newbs because the
choice is in the name, assuming we name them pristinely (I have faith!).

I'm also a little cooky too, but maybe this can spark some creativity in a
more wholistic solution for both sides.

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:
>
> GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0159-fix-private-access-levels.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<
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:
>
> GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> <GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
process.md#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<
https://github.com/apple/swift-evolution/blob/master/process.md>
> Thank you,
>
> -Doug
>
> Review Manager
>
>
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

anandabits · March 24, 2017, 12:25pm

`scoped` was the name originally proposed in SE-0025, changed by the core team on acceptance to `private`, and `file` was one of the suggestions for what used to be called `private`; I remember because I suggested it too; it was renamed to `fileprivate` after consideration of this alternative.

I believe the original proposal actually used `local` which I thought was not a good name. `scoped` didn't receive significant discussion (any that I recall) until after Swift 3 was already released.

···

Sent from my iPad

On Mar 24, 2017, at 6:11 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Mar 24, 2017 at 5:27 AM, Vinnie Hesener via swift-evolution <swift-evolution@swift.org> wrote:
This discussion escalated real quickly. There are some very bright minds in the mud right now, but I think there may still be a way to salvage this discussion.

Chris talked about there being two layers to Swift... the easy mode for adoption and outreach, then the advanced mode for taking over the world. This requires a delicate balance of features vs usability (e.g. MS Paint vs Photoshop). There are various ways to approach that balance, but they almost always require creativity and cooperation from the smartest guys in the room.

I'm not one of those guys, but let me throw out some food for thought. Is there a way to not only please both generalized arguments, but also solve the root of the problem? For instance, has anyone thought about why we even call things public, private, etc? Other than their initial meaning, the answer may be "other languages do it" or even better "that is what prevents confusion and dupe questions on stackoverflow". Fair enough.

I realize this would be jolting for most, but would anyone be asking the stackoverflow ether what a **scope** var was? How about a **file** func? How about a SO title: "What does **module** let myVar refer to?"

Don't we have the opportunity to offer, within reason, a large set of accessors that are self explanatory? I think it may solve the complexity for usefulness exchange because they are simply there for the advanced users that want to use them. There's no choosing for newbs because the choice is in the name, assuming we name them pristinely (I have faith!).

I'm also a little cooky too, but maybe this can spark some creativity in a more wholistic solution for both sides.

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through March 27, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.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/0159-fix-private-access-levels.md
> Reply text
> Other replies
> <https://github.com/apple/swift-evolution/blob/master/process.md#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
>
> Review Manager
>
>
>

_______________________________________________
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