We're now talking about making breaking changes, in addition to confusing scoping with access control?
Wouldn't it be far simpler just to have a scoped modifier to existing access levels?
private(scoped) var varName
internal(scoped)
public(scoped)
or just we could add scoped as a separate modifier, allowing scoped access without an explicit access level:
scoped [access level] var varName
scoped var varName
These seem like far better options than adding yet another access-level keyword (or making breaking changes to existing keywords), and eventually needing even more if we decide to add scoped access for more access levels.
In addition, adding a ‘local’ equivalent would imply the same guarantee of increased safety that current access levels provide, while a separate ‘scoped’ keyword makes it clearer that scoping is not proper access control.
If we add a scoped modifier, it helps set a precedent for future languages to not confuse access control with scope.
On the other hand, this proposal to add a new ‘scoped access level’ keyword seems like a step backwards for Swift.
------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <392C0559-FDA2-430B-8AE0-F8B0369B48D4@apple.com>
The review of SE-0025 “Scoped Access Level” ran from February 26...March 3, 2016. The core team is requesting a revision to the proposal that will then come up for a second public review:
The core team feels that Swift is a very “extension-oriented” language, where programmers are encouraged to put core functionality into the struct/class/enum/protocol definition and factor other functionality into extensions that each encapsulate some aspect of the type’s functionality. The proposed “local” access specifier fits that development methodology well, separating out the implementation details of an extension from the interface provided by that extension. While it is possible to place extensions in separate files to isolate them (and use file-private access), this is not always practical (because it might require nontrivial refactoring for existing code) and might have the unintended effect of requiring currently file-private declarations (that are only referenced within that file) to become internal declarations (once an extension is placed in a separate file).
The requested revision involves the proposed keyword, local. The core team feels that the most appropriate keyword for the proposed functionality is the existing private keyword. Other languages that have private access specifiers more closely align with the proposed locally-scoped behavior, so such a change would reduce friction for developers moving between the language and more naturally align when what the core team felt the keyword private implies.
Specifically, the core team is requesting a revised version of the proposal that changes the semantics of the existing private keyword to match those of the proposed local keyword, and introduce a new name for the existing private semantics that more strongly implies file-private access. Because this is a significant expansion in the scope of the change, the core team feels that we should have a second public review.
Doug Gregor
Review Manager
------------- End Message -------------