SE-0025: Scoped Access Level, next steps


(Thorsten Seitz) #1

+1

Now we only need to add submodule and protected :wink:

-Thorsten

路路路

Am 15. M盲rz 2016 um 14:58 schrieb Zach Waldowski via swift-evolution swift-evolution@swift.org:

I, too, prefer it to be more like this:

public // unchanged
module // currently internal
internal // currently private
private // new hotness

l8r
Sean

On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution swift-evolution@swift.org wrote:

+1

I like this a lot. Name ideas : enclosed, filelocal, fileonly, filelock, fileaccess, fileprivate, insidefile, inner. I also like Erica鈥檚 filebound & file fixed.

By Erica鈥檚 suggestion about switching鈥

  • public
  • modular, modulelock, packaged (module only)
  • internal (file only)
  • private

Designer . Developer . 铮 Nerd
Jo Albright

On Mar 14, 2016, at 8:18 PM, Chris Lattner via swift-evolution swift-evolution@swift.org wrote:

Per Doug鈥檚 email, the core team agrees we should make a change here, but would like some bikeshedding to happen on the replacement name for private.

To summarize the place we鈥檇 like to end up:

  • 鈥減ublic鈥 -> symbol visible outside the current module.
  • 鈥渋nternal鈥 -> symbol visible within the current module.
  • unknown -> symbol visible within the current file.
  • 鈥減rivate鈥 -> symbol visible within the current declaration (class, extension, etc).

The rationale here is that this aligns Swift with common art seen in other languages, and that many people using private today don鈥檛 want visibility out of their current declaration. It also encourages 鈥渆xtension oriented programming鈥, at least it will when some of the other restrictions on extensions are lifted. We discussed dropping the third one entirely, but think it is a useful and important level of access control, and when/if we ever get the ability to write unit tests inside of the file that defines the functionality, they will be a nicer solution to @testable.

The thing we need to know is what the spelling should be for the third one. Off hand, perhaps:

fileprivate
private(file)
internal(file)
fileaccessible
etc

Some other thoughts on the choice:

  • this will be a declaration modifier, so it will not 鈥渂urn鈥 a keyword.
  • if will be a uniquely Swift thing, so there is virtue in it being a googlable keyword.

Thoughts appreciated.

-Chris


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


swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I鈥檓 in favor of this too. Parameterizing the private syntax is nice, but
it introduces complications elsewhere. We should come up with a new
word, module seems good to me.

Sincerely,
Zachary Waldowski
zach@waldowski.me

On Mon, Mar 14, 2016, at 10:38 PM, Sean Heber via swift-evolution wrote:


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