SE-0025: Scoped Access Level, next steps

[Ilya_Belenkiy]

I'd like to keep "private" to be completely private and not allow class
injection to gain access, but this is an edge case that could be argued
either way. I can definitely live with a pure scoped access for
consistency and don't want to argue the edge case in a never ending
discussion.

I think that lexical scope is a well defined concept. The core team
requested only the change in names for access levels. At this point, I'd
like to limit the changes to that. We already had a very long discussion
about all of these topics.

···

On Sun, Mar 27, 2016 at 10:19 PM Brent Royal-Gordon <brent@architechies.com> wrote:

> 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

[Ilya_Belenkiy]

after a brief discussion, updated the proposal to limit `private` only to
the immediate scope.

adjustments to SE-0025 after the first review

···

On Sun, Mar 27, 2016 at 10:03 PM Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> wrote:

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

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

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

[Ilya_Belenkiy]

After today's discussion, I changed the proposal back to only describe the
new names (fileprivate etc.) and keep the lexical scope (I still want the
immediate scope, but after Jordan's explanation that it's not standard and
that other major languages don't do this, I decided to remove it.)

changes after the first review

(I am not a git expert, so I created a new pull request)

···

On Sun, Mar 27, 2016 at 10:03 PM Ilya Belenkiy via swift-evolution < swift-evolution@swift.org> wrote:

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

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

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

[Chris_Lattner]

I’ve seen a number of concerns on this list about moduleprivate, and how it penalizes folks who want to explicitly write their access control. I’ve come to think that there is yes-another possible path forward here (which I haven’t seen mentioned so far):

public
internal
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) Compared to Swift 2, there is almost no change. The only thing that changes is that some uses of Swift 2 “private” will be migrated to “fileprivate”, which makes the intent of the code much more clear.
4) fileprivate is the unusual and not-really-precedented-in-other-languages modifier, and it would still be “googable”.
5) The addresses the “excessively long” declmodifier problem that several people are concerned with.
6) Support for named submodules could be “dropped in” by parameterizing “internal”.

Thoughts?

-Chris

···

On Mar 23, 2016, at 10:13 PM, Chris Lattner <clattner@apple.com> 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.

[Joe_Groff]

I like this too. It also admits groupings between 'file' and 'module' in the future ('directory' or 'submodule' maybe), the lack of which has been often cited as another weakness in our current model.

-Joe

···

On Mar 14, 2016, at 6:47 PM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

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.

[Erica_Sadun]

+1 here too.

* It resolves my issues with public/internal vs public/private.
* As Ilya put it: "obvious at a glance"
* Uses one concept applied to different scopes.

-- E

···

On Mar 14, 2016, at 7:50 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 14, 2016, at 6:47 PM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

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.

I like this too. It also admits groupings between 'file' and 'module' in the future ('directory' or 'submodule' maybe), the lack of which has been often cited as another weakness in our current model.

[anandabits (Matthew Johnson)]

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.

I like this too. It also admits groupings between 'file' and 'module' in the future ('directory' or 'submodule' maybe), the lack of which has been often cited as another weakness in our current model.

+1 here too.

* It resolves my issues with public/internal vs public/private.
* As Ilya put it: "obvious at a glance"
* Uses one concept applied to different scopes.

Tentative +1 here as well, but I think we should continue the bikeshed. I’m not yet certain this is the best we can come up with...

···

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

On Mar 14, 2016, at 7:50 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 14, 2016, at 6:47 PM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

-- E

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

[BigZaphod (Sean Heber)]

How would you handle translating the existing private(set) and the like with this syntax? It seems like it could get confusing and perhaps end up in a situation where you have something like private(file, set) but then you have to constantly remember which order the parameters are in.

l8r
Sean

···

On Mar 14, 2016, at 8:47 PM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

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

[BigZaphod (Sean Heber)]

Although really, why not just use “file” instead of “internal” since it won’t burn any keywords or cause any other conflicts as far as I know.

l8r
Sean

···

On Mar 14, 2016, at 9:38 PM, Sean Heber <sean@fifthace.com> wrote:

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

[hartbit (David Hart)]

I think swapping internal is dangerous because some languages already use internal to represent a module scope (C# for example).

I'm also quite a fan of:

private(module)
private(file)
private

But then Im not sure how we would modify property setters:

private(file)(set) ??

···

Sent from my iPhone

On 15 Mar 2016, at 03:38, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

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

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

[zwaldowski (Zachary Waldowski)]

I'm 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:

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

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

[Charles_Kissinger]

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

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

I like these best out of what’s been suggested so far. I agree with those that think the parameterized versions are too long and unnecessary.

—CK

···

On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

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

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

[Erica_Sadun]

Oddball cases:

Global visibility, private settable public private(set) var foo: String
Global visibility, module settable public private(module set) var foo: String
Module visibility, file settable private(module, file set) var foo: String

of course if module visibility is the default, that might be instead:

Module visibility, file settable private(file set) var foo: String

-- E

···

On Mar 15, 2016, at 2:14 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

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

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

[jrose (Jordan Rose)]

Really? In the following code, the nested type and the local method are definitely in the same lexical scope by my understanding of "lexical scope":

struct Foo {
local static func foo() {}
struct Nested {
  init() {
    Foo.foo()
  }
}
}

I guess this is something else that would need to be clarified if/when the proposal returns to review.

Jordan

···

On Mar 16, 2016, at 19:02 , Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

The access level discussed in the proposal already hides the members from nested types.

[Joanna_Carter]

I'm tempted to wade in on the KISS principle with :

public
internal
file
private

"It does what it says on the tin" :-)

Joanna
Carter Consulting

Envoyé de mon iPad

···

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

[Panajev (Goffredo Marocchi)]

Agreed, seems like a good way to go.

[[iOS messageWithContent:webContent] broadcast]

···

On 24 Mar 2016, at 07:04, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

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?

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

[anandabits (Matthew Johnson)]

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

I don't think it would make sense at all to allow an outer type to see private members of a nested class. That would break the semantics of private meaning "containing scope".

However, with Chris's suggestion of using identifiers as parameters, maybe we could eventually have something like private(OuterTypeName) to specify the precise level of access desired.

···

Sent from my iPad

On Mar 24, 2016, at 5:07 AM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

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

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

[Ilya_Belenkiy]

We already have other precedents for combining multiple words into a
keyword. I don't that these will be any different.

···

On Thu, Mar 24, 2016 at 7:02 AM Dany St-Amant via swift-evolution < swift-evolution@swift.org> wrote:

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

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

[Panajev (Goffredo Marocchi)]

I think that supercalifragilisticexpialidocious may benefit from lowerCamelCasing ;).

[[iOS messageWithContent:webContent] broadcast]

···

On 24 Mar 2016, at 11:02, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

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?

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

[Ilya_Belenkiy]

The discussion was about the other direction: whether a nested class should
have access to private members of the outer class.

···

On Thu, Mar 24, 2016 at 9:35 AM Matthew Johnson <matthew@anandabits.com> wrote:

Sent from my iPad

On Mar 24, 2016, at 5:07 AM, Ilya Belenkiy via swift-evolution < > swift-evolution@swift.org> wrote:

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

I don't think it would make sense at all to allow an outer type to see
private members of a nested class. That would break the semantics of
private meaning "containing scope".

However, with Chris's suggestion of using identifiers as parameters, maybe
we could eventually have something like private(OuterTypeName) to specify
the precise level of access desired.

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

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