SE-0025: Scoped Access Level, next steps

[Chris_Lattner]

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” a keyword.
- if will be a uniquely Swift thing, so there is virtue in it being a googlable keyword.

Thoughts appreciated.

-Chris

[jberry (James Berry)]

I like fileprivate, if that’s the only change. On the other hand, if we want to consider a broader change, what about:

  private symbol visible within the current declaration (class, extension, etc).
  private(module) symbol visible within the current module.
  private(file) symbol visible within the current file.

James

···

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

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” a keyword.
- if will be a uniquely Swift thing, so there is virtue in it being a googlable keyword.

Thoughts appreciated.

[Erica_Sadun]

What color is your bikeshed?

I don't suppose you'd consider swapping private and internal (since the opposite of public is private, and internal means inside)?

Anyway, there's fileScoped (or filescoped), access(file) (which has the option of being used for access with module and global),
filedelimited, filefixed, filebounded, filebound, filerestricted.

You may want constructing phrases around bounding, restrictions, access, limitations, visibility, and local.

-- E

···

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

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” 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

[Jo_Albright1 (Jo Albright)]

+1

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

By Erica’s 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’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” 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

[Shawn_Erickson]

Very much like the thinking.

I guess it isn't feasible at this point to change `internal` to mean file
scoped? That could avoid the need for another qualifier by simply
leveraging the default of module scope for things without an access
qualifier.

As you know the default of whole module means most developers need never
use access control unless they desire to reduce access scope (e.g. file
scope, dec scoped). Those working on frameworks would be the ones to
leverage public in addition to the other levels.

Of the top of my head: ` pubic`, `internal` (and `internal(module`)),
`internal(file)`, `private`. This makes public and private being closest to
other languages as you noted with internal being more swift nuanced.

-Shawn

···

On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> symbol visible within the current declaration (class,
extension, etc).

[Shawn_Erickson]

More thinking out loud...

`public` -> exported from module
<omitted> -> module scoped (e.g. current internal)
`private` -> class, struct, etc. scoped (e.g. new private)
`private(file)` or `file` -> file scoped (e.g existing private)
`private(module)` or `module` or `internal` -> module scoped (e.g. current
internal)

public var foo = 0 // marks default getter and setter public

public var foo = 0 { // marks default getter and setter public however...
  private set // marks default setter private
}

var foo = 0 { // marks default getter and setter module scoped however...
  public get // marks default getter public
  private set // marks default setter private
}

public var foo: Int { ... } // marks provided getter public, read-only

var foo: Int { // marks provided getter and setter module scoped
however...
  public get { ... } // marks provided getter public
  private set { ... } // marks provided setter private
}

public var foo: Int { // marks provided getter and setter public however...
  get { ... } // not specified, inherit access level public
  private set { ... } // marks provided setter private
}

var foo: Int { // marks provided getter and setter module scoped
however...
  get { ... } // not specified, inherit access level module scoped
  private set { ... } // marks provided setter private
}

private(module) var foo: Int { // marks provided getter and setter module
scoped however...
  get { ... } // not specified, inherit access level module
scoped
  private(file) set { ... } // marks provided setter file scoped
}

var foo: Int { // marks provided getter and setter module
scoped however...
  private(file) get { ... } // not specified, inherit access level module
scoped
  private set { ... } // marks provided setter file scoped
}

...etc...

public subscript(index: Int) -> Int { ... } // marks provided getter
public, read-only

public subscript(index: Int) -> Int { // marks provided getter and setter
public
  get { ... } // not specified, inherit access
level public
  set { ... } // not specified, inherit access
level public
}

public subscript(index: Int) -> Int { // marks provided getter and setter
public however...
  get { ... } // not specified, inherit access
level public
  private set { ... } // marks provided setter private
}

subscript(index: Int) -> Int { // marks provided getter and setter module
scoped however...
  get { ... } // not specified, inherit access level
module scoped
  private set { ... } // marks provided setter private
}

subscript(index: Int) -> Int { // marks provided getter and setter module
scoped however...
  public get { ... } // marks provided getter public
  private set { ... } // marks provided setter private
}

subscript(index: Int) -> Int { // marks provided getter and setter module
scoped however...
  public get { ... } // marks provided getter public
  private(file) set { ... } // marks provided setter file scoped
}
...etc...

···

On Mon, Mar 14, 2016 at 5:18 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> symbol visible within the current declaration (class,
extension, etc).

[Tino]

I agree that the current "private" is useful, and would rather keep everything as-is than remove this scope.
I'm neutral on adding a new access level, but don't like the "private(file)"-syntax:
The issues with properties could be solved (my preference would be "private <file> (set) var x: Int"), but imho all access levels should be specified in the same way (that would put me in the "local" camp).

If the access model is changed, i vote for a broad discussion about the topic as whole to minimize breaking changes (for example, it would be nice to have an elegant way to express that a method can be overridden by a subclass, but not be called).

Tino

[David_Ungar1 (David Ungar)]

First post to Swift evolution, please bear with me: the following is a bit wild, but something to think about for the future, maybe.

Swift had three, and will now have four levels of scoping. In the future, might there be five? A scope that spans a limited set of modules, or a scope that only applies within a region of a declaration?
Maybe scope modifiers should be something like: scope(all), scope(module), scope(file), scope(declaration).
In other words, something that says it is a scope declaration, followed by a noun that names what the scope is. If additional scopes are needed in the future, it might be easier to add them. For instance, if there’s a way to name a collection of modules, there could be a scope(module-collection-name) modifier.

Hope you enjoy this thought,

- David

···

Per Doug’s 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’d like to end up:

- “public” ->symbol visible outside the current module.
- “internal” ->symbol visible within the current module.
- unknown ->symbol visible within the current file.
- “private” ->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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” a keyword.
- if will be a uniquely Swift thing, so there is virtue in it being a googlable keyword.

Thoughts appreciated.

-Chris

[michelf (Michel Fortin)]

To summarize the place we’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> symbol visible within the current declaration (class, extension, etc).

domestic?

I'm not too thrilled to see the list extend to four words though. The more visibility levels we have between public and private the more subtle the difference and meaningless the choice of word. So I think I'll fall in the camp of private(file)`.

Speaking of meaning though, there's one thing bothering me about altering the meaning of `private` to mean what `local` meant in the Scoped Access Level proposal.

The new `private` keyword will sometime mean file-private and sometime mean declaration-private depending on where it is. That's because file-private and declaration-private are the same thing for elements not part of a declaration. With the `local` keyword, I'd have expected the compiler to emit an error for this declaration found at the root of a file:

  local class A {} // error: use `private` at file scope

thus, restricting `local` to where it actually had an effect: inside declarations. It's useful when seeing `local` to know that this symbol will not be accessible everywhere in the file.

But does this same restriction makes sense for `private`? I think not. And that will make the `private` attribute have the same meaning as `private(file)` when at the root of the file. I'm thus privileging `private(file)` because it makes sense for the compiler to do this:

  private(file) class A {} // error: use `private` at file scope

whereas using a different keyword would make things look messy. Note that I'm reversing the error here: the compiler wants `private` (the old `local`) to be used at file scope, and `private(file)` would be reserved for use inside declarations.

Put simply: whatever the keyword we end up with, oftentimes it'll have the same meaning as `private` and the compiler will have to force your hand with one or the other. In my opinion the old approach with the `local` keyword was cleaner because there was no overloaded meaning.

···

--
Michel Fortin
https://michelf.ca

[James_Campbell]

Just wondering, wouldn't private be enougth for a class level declaration ?

Not sure why we need a file baed one.

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Tue, Mar 15, 2016 at 12:18 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility
out of their current declaration. It also encourages “extension 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 “burn” 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

[hlovatt (Howard Lovatt)]

Bikeshedding!

I would suggest three things:
Make the access modifies annotations, i.e. they are spelt with an @ and use lower-camel case (which I think was the result of a previous Swift Evolution proposal, otherwise what ever was agreed for annotations)
Move them to the end of the declaration because they clutter the declaration at present, e.g. struct Foo: Bar @public { … }
Names:
@public
@module
@file
@private

Cheers,

— Howard.

···

On 15 Mar 2016, at 8:18 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” 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

[Brent_Royal-Gordon]

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> symbol visible within the current declaration (class, extension, etc).

I think moving `private` to this new access control level because it's the most private one we currently have sets a bad precedent. If we add a fifth level in Swift 4 (say, one that hides the member from nested types), does that now become `private` and we need to come up with a new name for the fourth level? Will users ever be able to get used to what the keywords actually mean?

Rather than use relative terms, let's use absolute ones. An extreme, imperfect example of what I mean:

* exported
* module
* file
* scope

Then if we add other access levels in the future, we don't have to worry about reshuffling the existing names, because they will all still be correct. We just have to come up with a good name for the new one.

···

--
Brent Royal-Gordon
Architechies

[Tino]

Just had an idea for a different approach for access levels (as if things aren't complicated enough ;-) - but I'm only brainstorming here):
The problem of access levels isn't limited to programming — file systems have to deal with it as well.
So, ignoring ACLs for a moment, imagine

protected x: Int
protected(set) public y: Int

would be expressed as

module(read, write) x: Int
public(read) y: Int

As far as I can see, this syntax is less convenient, but could allow things like "public(override)" to express that a method can't be called outside the module, but still can be overridden by subclasses.
Any thoughts on this?

Tino

[Ilya_Belenkiy]

It looks like people finished the discussion for the best access level
names. How should I update the proposal?

···

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

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility
out of their current declaration. It also encourages “extension 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 “burn” 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

[Chris_Lattner]

<responding to several posts in this thread at once>

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

What we do with private setters is orthogonal from this proposal, so I’m going to ignore it in this thread. After SE-0025 is resolved, it would be great to have another thread/proposal that discusses reskinning private(set) - presumably as just a modifier on the setter.

Similarly, this proposal has nothing to do with “protected” or any other type based access control, so I don’t delve into that at all either.

I’ve seen several proposals that seem promising:

I like fileprivate, if that’s the only change. On the other hand, if we want to consider a broader change, what about:

  private symbol visible within the current declaration (class, extension, etc).
  private(module) symbol visible within the current module.
  private(file) symbol visible within the current file.

I love how this establishes a family with different levels of access control, and unites them under the idea of "levels of being private”. I also like how people would commonly only ever write public and private (because “private(module)” is the default, and "private(file)" is obscure). However, parenthesized modifiers that take a keyword (as opposed to an identifier) are a bit weird and awkward, so it would be nice to avoid them if possible.

public
private-module
private-file
private

This follows the same sort of structure as James’ proposal, without the parens. It has the same advantages, but trades them with hyphenated decl modifiers. We don’t do that, but it is a good direction.

How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:

  public
  moduleprivate
  fileprivate
  private

The advantages, as I see them are:
1) We keep public and private meaning the “right” and “obvious” things.
2) The declmodifiers “read” correctly.
3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.
4) The unusual ones would be “googable”.
5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). Putting an identifier in the parens is much more natural than putting keywords in parens.

What do you all think?

-Chris

···

On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 14, 2016, at 5:49 PM, James Berry <jberry@rogueorbit.com> wrote:
On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

[Ilya_Belenkiy]

I created a pull request with the updated proposal:

adjustments to SE-0025 after the first review

···

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

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility
out of their current declaration. It also encourages “extension 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 “burn” 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

[marc_hoffman]

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.

won’t that break *every* single member written today, given that “no specifier” is used for internal (i.e. most code in most apps), currently?

—marc

[Eric_Summers]

What about:
public
private
private(module) // instead of internal
private(file) or private(test)

Eric

···

Sent from my iPhone

On Mar 14, 2016, at 5:41 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

What color is your bikeshed?

I don't suppose you'd consider swapping private and internal (since the opposite of public is private, and internal means inside)?

Anyway, there's fileScoped (or filescoped), access(file) (which has the option of being used for access with module and global),
filedelimited, filefixed, filebounded, filebound, filerestricted.

You may want constructing phrases around bounding, restrictions, access, limitations, visibility, and local.

-- E

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

Per Doug’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” 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

[BigZaphod (Sean Heber)]

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’s filebound & file fixed.

By Erica’s 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’s 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’d like to end up:

- “public” -> symbol visible outside the current module.
- “internal” -> symbol visible within the current module.
- unknown -> symbol visible within the current file.
- “private” -> 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’t *want* visibility out of their current declaration. It also encourages “extension 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 “burn” 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

[Ilya_Belenkiy]

I really like James's idea:

private symbol visible within the current declaration
(class, extension, etc).
private(module) symbol visible within the current module.
private(file) symbol visible within the current file.

this is very precise and crystal clear. All other already suggested names
have room for interpretation. These are obvious at a glance.

···

On Mon, Mar 14, 2016 at 8:49 PM James Berry via swift-evolution < swift-evolution@swift.org> wrote:

> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Per Doug’s 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’d like to end up:
>
> - “public” -> symbol visible outside the current module.
> - “internal” -> symbol visible within the current module.
> - unknown -> symbol visible within the current file.
> - “private” -> 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’t *want*
visibility out of their current declaration. It also encourages “extension
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 “burn” a keyword.
> - if will be a uniquely Swift thing, so there is virtue in it being a
googlable keyword.
>
> Thoughts appreciated.

I like fileprivate, if that’s the only change. On the other hand, if we
want to consider a broader change, what about:

        private symbol visible within the current
declaration (class, extension, etc).
        private(module) symbol visible within the current module.
        private(file) symbol visible within the current file.

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