SE-0025: Scoped Access Level, next steps

Evolution Discussion
21

How about

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

?

···

Sent from my iPhone

On 15 Mar 2016, at 00:49, 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

22

I agree with you Tino that we should not stop here, but I would break it down in smaller proposals that had the biggest breakage in the language but still could all fit into Swift 3. It is one of the last chances of being allowed to break source and ABI compatibility and we ought to make it count IMHO.

···

Sent from my iPhone

On 15 Mar 2016, at 09:45, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

23

I am really not in favor of the parametrized access keywords.

To me, private(module) and private(file) seem redundant. Module already implies it is restricted to the module, and file already implies it is restricted to the file so the private keyword just seems unnecessary in my opinion.

“unknown” could just be local or file
“internal” really should become “module” or “modular” for clarity reasons

···

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).

24

I like the idea of public and then varying degrees of private (with the default being the most private). Public values are published outside of the build target.

However, I have a question how we would express the concept of mixed property access levels, for instance with a private (to the scope) setter and private (to the module) getter.

-DW

···

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

  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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

25

I think in the referenced example the new private would mean “class and extensions”, with file being the new private, which I think is confusing.

My preference would be:

public
module (currently internal)
protected (class and extensions)
private

protected is widely used to mean this in other languages and fits well semantically between public and private. The other alternative could be just to re-use the class and struct keys; i.e- a “class” accessible property means the class, its descendants and its extensions know about it, with struct being the same for structs (in which case it’s just extensions, so the distinction might be nice for clarity). Alternatively we could re-use the extension keyword, to indicate that the property/method is available to extensions (including sub-classes).

···

On 15 Mar 2016, at 23:40, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

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 <mailto:james@supmenow.com>⎥supmenow.com <http://supmenow.com/&gt;
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 <mailto: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 <mailto: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

26

The access level discussed in the proposal already hides the members from
nested types. The goal is to make something completely hidden outside of
the scope. (otherwise, it would be possible to get access to something by
simply inserting a nested class and without modifying the original class or
extension definition). We discussed it during the review. So it is already
the most private, and the name matches the meaning.

One of the goals of the core team in the response was to preserve the terms
of art. In that sense, public and private make the most sense, the other
two (internal and what today is called private) are not universal.

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?

···

On Wed, Mar 16, 2016 at 7:01 PM Brent Royal-Gordon 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).

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

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

27

I like it. Searchable and clear.

···

        public
        moduleprivate
        fileprivate
        private

…
What do you all think?

-Chris

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

28

Coming in late, but:

* “internal”, as already mentioned, has prior art as meaning “private to a package/project”, so should stay as it is
* fileprivate looks good, obvious, straightforward and googlable to me
* private(file) introduces a bunch of visual noise that I don't like
* whoo-hoo, this discussion is impossible to read through — the power of bike-shedding!

A.

···

On Mar 18, 2016, at 7:46 PM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

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 <mailto: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 <mailto: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

29

The think I fear with moduleprivate and fileprivate, is that someone will one day suggest to lowerCamelCase them. The parenthesized version was de-facto preventing my fear from ever being reality.
Obviously, I am on the "all keywords should be all lowercases" team.

Dany

···

Le 24 mars 2016 à 01:13, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

<responding to several posts in this thread at once>

[..snip..]
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?

30

I like it very much.

···

On 24 Mar 2016, at 06:13, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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?

31

<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?

+1. This is probably the best option so far. We need to pick something and move on at this point.

···

Sent from my iPad

On Mar 24, 2016, at 12:13 AM, Chris Lattner 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:
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:

-Chris

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

32

Thanks, Chris, for summing up and pulling this back together.

I’m +1 on your suggestion of public, moduleprivate, fileprivate, and private. I share your feeling of slight awkwardness about the parens in my previous suggestion.

As to other’s expressed concerns about smashedlowerkeywords, they don’t bother me too much. I prefer consistency here. As an alternative I’d find lower_snake_case acceptable, but would like to see it applied consistently, and thus also to associatedtype, etc. I don’t like lowerCamelCase for keywords. But if I had my druthers it would be to maintain the status quo of smashedlower.

James

···

On Mar 23, 2016, at 10:13 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

<responding to several posts in this thread at once>

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.

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:

On Mar 14, 2016, at 5:49 PM, James Berry <jberry@rogueorbit.com> wrote:

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.

On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

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

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

33

Why is it important to highlight word boundaries in so many other
conventions in Swift but not in this one? What would be lost with this
alternative?

public
module_private
file_private
private

Is it just the extra (chorded, on US keyboards) keystroke? I think the
readability benefits of clear word boundaries far outweigh the keystroke
cost (especially with good editor auto-complete).

I also think the precedent of nameslikethis is a dangerous one for
readability. It's easy to say this is "just for this limited area of the
language," but witness how associatedtype is already used to support
moduleprivate and friends. Precedents matter, and I think this is not a
good one.

-John

···

On Thu, Mar 24, 2016 at 1:13 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution < > swift-evolution@swift.org> wrote:
> 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

34

It's very consistent with other keywords. I wish compound keywords were
joined with a dash or something that made them easier to read, but I guess
it's too late now. If we have associatedtype, it makes sense to use
moduleprivate (I saw that the name associatedtype was discussed extensively
but didn't participate in the discussion; I am sure that it was given a lot
of thought). If we could change this, I'd suggest keyword names with dashes
everywhere, but if not, these names work well and is a great compromise for
everything I've seen in this thread.

I am not worried about the length because the 2 most frequently written
keywords would be public and private. Moduleprivate is the default, and
file private will not be used as often as private.

One question: should the proposal be explicit about access control for
nested classes? We discussed it here briefly (I wanted private to be
completely private to the class or extension itself while 2 other people
wanted a nested class to have access to the outer class.)

···

On Thu, Mar 24, 2016 at 1:13 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

<responding to several posts in this thread at once>

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.

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:

On Mar 14, 2016, at 5:49 PM, James Berry <jberry@rogueorbit.com> wrote:
> 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.

On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution < > swift-evolution@swift.org> wrote:
> 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

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

35

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

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

I'm not sure my wording will be perfect here, but I will try: I still believe that private is implied in "module" and "file" and the problem is in the name of the plain "private" keyword.

You may say private is obvious, but when you have moduleprivate and fileprivate, the natural question I ask is "What remaining kind of private is there?" so private's obviousness is muddied for me when next to moduleprivate and fileprivate.

I will say I would prefer these keywords to the proposed parameter keywords. I just think:

file -> implies file only
module -> implies module only

where adding private to them only adds noise (I.e. fileprivate and moduleprivate)

Brandon

36

I support this for all the enumerated reasons. This is clean, simple, and obvious.
It retains the benefits and avoids the negatives of the parenthesized versions.

One correction: "googlable" not "googable", because that's how pedants roll.
(cite: Muphry's law - Wikipedia <https://en.wikipedia.org/wiki/Muphry's_law&gt;\)

-- E

···

On Mar 23, 2016, at 11:13 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
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.

37

+1. It also has the advantage of getting rid of the confusing distinction between “private” and “internal”—which is backwards from the usual “API/SPI/IPI” terminology.

-Colin

···

On Mar 24, 2016, at 1:13 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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.

38

I like the way it goes, but I don’t like the nospacebetweenwords convention. module_private and file_private look better IMHO.

···

Le 24 mars 2016 à 06:13, Chris Lattner via swift-evolution <swift-evolution@swift.org> a écrit :

<responding to several posts in this thread at once>

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.

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:

On Mar 14, 2016, at 5:49 PM, James Berry <jberry@rogueorbit.com> wrote:

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.

On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

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

39

I created a pull request with the updated proposal:
adjustments to SE-0025 after the first review by ilyathewhite · Pull Request #234 · apple/swift-evolution · GitHub

As long as you're updating the proposal, I'd like to suggest you explain more explicitly the visibility of members marked with your new access level. I know I was surprised that nested types cannot see a parent type's members, and I've seen other people in this thread who seem to believe this behaves like the classic C++/Java `private`, where extensions can see the members. I'm sure you think it's fully specified, but it just seems to be a point of confusion.

···

--
Brent Royal-Gordon
Architechies

40

<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.

If we borrow the "drop in" from below of private(foo.bar.baz), then maybe:

private(module) // expands to current module
private(#file) // expands to current file

This is slightly more awkward/one character longer, but now it's an identifier in parentheses (or something that expands to an identifier).

I'm not sure I like this in practice unless it is fairly rare to actually have to type. If "private" at the top level of a file meant fileprivate (as I suggested in my other reply a few minutes ago) that would significantly reduce the need to type something other than just private.

···

On Mar 24, 2016, at 01:13, Chris Lattner 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:
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:
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

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