Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Michael M. Mayer via swift-evolution]

I am opposed to any change to the current access level system.  
What we have now is simple, approachable and handles all real cases 
for limiting or granting access.  Any additions will just serve to 
complicate the current system without sufficient offsetting benefit.  
Further additions will just handle cases for which there are already 
other viable solutions.

Furthermore, any additions to the access level system would be contrary 
to the stated goal of streamlining the Swift language.

Thank you for the opportunity to contribute to the discussion.

Regards, Michael
m.may...@gmail.com

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Wallacy via swift-evolution]

Em sex, 1 de abr de 2016 às 01:31, Ilya Belenkiy via swift-evolution <
swift-evolution@swift.org> escreveu:

> With these names we lose consistency. The current scheme makes it very
> clear that each next level is a subset of the previous level. With
> "internal", fileprivate looks out of place.
>
> We have several goals for all the names:
> 1) obvious
> 2) using standard terms
> 3) short
> 4) consistent
>
> This discussion shows that we cannot have all of them. We have to pick
> something at the expense of something else.
>
> For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that
> with this order
>
> public
> moduleprivate
> fileprivate
> private
>
> is the best so far.
>
> public
> internal
> fileprivate
> private
>
> is not as consistent. It's also not as obvious, given that many people
> proposed to use internal to mean fileprivate. The biggest advantages of
> these names are that there is less change and short words. If these are the
> most important goals, then my original proposal is even better:
>
> public
> internal
> private
> scoped
>
>
For me this is good, keep  untouched the actual public/internal/private and
just add a new word for the new access level.

It's a non-breaking change, everything retains its meaning, the added name
> is very clear, and all the names are very short. The biggest problem here
> is "private" -- it's not the most private that the language provides, and
> most people would expect that.
>
> Here is another one like that (it solves the "private" problem at the
> expense of using non-standard terms):
>
> public
> internal
> local
> scoped
>
> My main point is that we cannot have everything. We have to pick the order
> of importance.
>
> We heard many times that "short" is not the goal of Swift. Instead, it's
> clarity. If this is the case, then I think
>
> public
> moduleprivate
> fileprivate
> private
>
> is the clearest we've seen. Nobody could possibly be confused about the
> meaning of these names. I doubt that moduleprivate will be required to
> spell out in any style guide, but even so, it's not so bad. We have many
> frequently used class names that are much longer.
>
> On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
>>
>> 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
>> ___
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Xiaodi Wu via swift-evolution]

In terms of alternatives to fileprivate, I just want to chime in to say
that "filewide" seems to be a term that people seem to reach for in
describing this scope, based on a quick Google search.

It's readable, IMO, and definitely an adjective, it breaks no new ground in
terms of coining a new term, and it is adequately descriptive. Plus, it
avoids the issue of having two things named fileprivate and [bona fide]
private.

For those reasons, it's got my vote over "file", "fileprivate", "infile",
"intrafile", etc.

On Fri, Apr 1, 2016 at 11:11 AM Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

> How about:
>
> notprivateatall
> notveryprivate
> mostlyprivate
> stayout!!!private
>
> Sorry. April fools.. :-)
>
> On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> "or within my whole program (external)". That caused a double-take on its
> own.
>
> external things are not within, they are outside. 'external' could be a
> replacement term for 'public', not for 'internal'.
>
> This may well be a subjective thing, but I don't think in files, I think
> in modules because that's been the default for several years now. If I
> create a new type I am implicitly making it visible to everywhere within
> this module; it is not outside the module so it is not external. I may then
> choose to make it less visible, but it does not 'go inside' when I do this.
>
> If you think in files, I cannot say you are wrong, because it is
> subjective. But this is why I have been arguing for non-subjective
> keywords. I cannot make 'fileprivate' pretty for you but I do know that
> when we both read it we both understand what it means. That's why it hasn't
> gone away: it satisfies the criterion of clarity.
>
> Find a pretty alternative with the word 'file' baked into it and I'm with
> you.
>
> On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber  wrote:
>
>> A new type is implicitly visible *outside* of the file it is defined in
>> and hence it is “external” from that point of view. This arrangement seems
>> more “human” to me. Someone just learning isn’t going to know about modules
>> or how the compiler is treating things anyway and they would almost never
>> run into “external” because it’s the default and there’s no reason to
>> specify it most of the time. IMO, this “fits” how I think about source code
>> while I’m writing it - where do I want to be able to use this symbol?
>> Either hidden away and safe (private), inside this file I’m working with
>> (internal), or within my whole program (external).
>>
>> l8r
>> Sean
>>
>>
>> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien 
>> wrote:
>> >
>> > A new type is implicitly internal to a module. Implicitly specifying it
>> as 'external' is just plain confusing.
>> >
>> > On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > I know this is kind of winding down, and there seems to be a kind of
>> begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue),
>> but I still really don’t like it so I’m going to toss out my current
>> favorite configuration and try to stop caring and defer to the core team to
>> make an executive decision so we can all move on with our lives. :P
>> >
>> > public - unchanged, visible “everywhere"
>> > external - visible outside of the file (module, the default)
>> > internal - visible only within the file
>> > private - visible only within the scope
>> >
>> > I really like the existing private and I use it a lot to build
>> collections of small classes and structs that work together rather than a
>> large class/struct that tries to “be everything”. In those scenarios,
>> traditional OO private would be too restrictive and even a “protected”
>> access type wouldn’t work because I’m trying to avoid building inheritance
>> hierarchies. I really need something like “friend” (ugly) or the, imo, much
>> more elegant file-scoped access and if that one is renamed “fileprivate”
>> I’ll be really sad seeing such an ugly label all over the place. I’d go so
>> far as to suggest that an ugly name for this access level would actively
>> discourage its use and while some might have that as a goal, to me that
>> would encourage the creation of larger “do everything” classes instead of
>> clusters of smaller classes and structs and protocols.
>> >
>> > l8r
>> > Sean
>> >
>> > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > >
>> > >> 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 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

How about: 

notprivateatall
notveryprivate
mostlyprivate
stayout!!!private

Sorry. April fools.. :-) 

> On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> "or within my whole program (external)". That caused a double-take on its own.
> 
> external things are not within, they are outside. 'external' could be a 
> replacement term for 'public', not for 'internal'.
> 
> This may well be a subjective thing, but I don't think in files, I think in 
> modules because that's been the default for several years now. If I create a 
> new type I am implicitly making it visible to everywhere within this module; 
> it is not outside the module so it is not external. I may then choose to make 
> it less visible, but it does not 'go inside' when I do this.
> 
> If you think in files, I cannot say you are wrong, because it is subjective. 
> But this is why I have been arguing for non-subjective keywords. I cannot 
> make 'fileprivate' pretty for you but I do know that when we both read it we 
> both understand what it means. That's why it hasn't gone away: it satisfies 
> the criterion of clarity.
> 
> Find a pretty alternative with the word 'file' baked into it and I'm with you.
> 
> On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber  > wrote:
> A new type is implicitly visible *outside* of the file it is defined in and 
> hence it is “external” from that point of view. This arrangement seems more 
> “human” to me. Someone just learning isn’t going to know about modules or how 
> the compiler is treating things anyway and they would almost never run into 
> “external” because it’s the default and there’s no reason to specify it most 
> of the time. IMO, this “fits” how I think about source code while I’m writing 
> it - where do I want to be able to use this symbol? Either hidden away and 
> safe (private), inside this file I’m working with (internal), or within my 
> whole program (external).
> 
> l8r
> Sean
> 
> 
> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien  > > wrote:
> >
> > A new type is implicitly internal to a module. Implicitly specifying it as 
> > 'external' is just plain confusing.
> >
> > On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution 
> > > wrote:
> > I know this is kind of winding down, and there seems to be a kind of 
> > begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), 
> > but I still really don’t like it so I’m going to toss out my current 
> > favorite configuration and try to stop caring and defer to the core team to 
> > make an executive decision so we can all move on with our lives. :P
> >
> > public - unchanged, visible “everywhere"
> > external - visible outside of the file (module, the default)
> > internal - visible only within the file
> > private - visible only within the scope
> >
> > I really like the existing private and I use it a lot to build collections 
> > of small classes and structs that work together rather than a large 
> > class/struct that tries to “be everything”. In those scenarios, traditional 
> > OO private would be too restrictive and even a “protected” access type 
> > wouldn’t work because I’m trying to avoid building inheritance hierarchies. 
> > I really need something like “friend” (ugly) or the, imo, much more elegant 
> > file-scoped access and if that one is renamed “fileprivate” I’ll be really 
> > sad seeing such an ugly label all over the place. I’d go so far as to 
> > suggest that an ugly name for this access level would actively discourage 
> > its use and while some might have that as a goal, to me that would 
> > encourage the creation of larger “do everything” classes instead of 
> > clusters of smaller classes and structs and protocols.
> >
> > l8r
> > Sean
> >
> > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution 
> > > > wrote:
> > >
> > >> 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 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

"or within my whole program (external)". That caused a double-take on its
own.

external things are not within, they are outside. 'external' could be a
replacement term for 'public', not for 'internal'.

This may well be a subjective thing, but I don't think in files, I think in
modules because that's been the default for several years now. If I create
a new type I am implicitly making it visible to everywhere within this
module; it is not outside the module so it is not external. I may then
choose to make it less visible, but it does not 'go inside' when I do this.

If you think in files, I cannot say you are wrong, because it is
subjective. But this is why I have been arguing for non-subjective
keywords. I cannot make 'fileprivate' pretty for you but I do know that
when we both read it we both understand what it means. That's why it hasn't
gone away: it satisfies the criterion of clarity.

Find a pretty alternative with the word 'file' baked into it and I'm with
you.

On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber  wrote:

> A new type is implicitly visible *outside* of the file it is defined in
> and hence it is “external” from that point of view. This arrangement seems
> more “human” to me. Someone just learning isn’t going to know about modules
> or how the compiler is treating things anyway and they would almost never
> run into “external” because it’s the default and there’s no reason to
> specify it most of the time. IMO, this “fits” how I think about source code
> while I’m writing it - where do I want to be able to use this symbol?
> Either hidden away and safe (private), inside this file I’m working with
> (internal), or within my whole program (external).
>
> l8r
> Sean
>
>
> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien 
> wrote:
> >
> > A new type is implicitly internal to a module. Implicitly specifying it
> as 'external' is just plain confusing.
> >
> > On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I know this is kind of winding down, and there seems to be a kind of
> begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue),
> but I still really don’t like it so I’m going to toss out my current
> favorite configuration and try to stop caring and defer to the core team to
> make an executive decision so we can all move on with our lives. :P
> >
> > public - unchanged, visible “everywhere"
> > external - visible outside of the file (module, the default)
> > internal - visible only within the file
> > private - visible only within the scope
> >
> > I really like the existing private and I use it a lot to build
> collections of small classes and structs that work together rather than a
> large class/struct that tries to “be everything”. In those scenarios,
> traditional OO private would be too restrictive and even a “protected”
> access type wouldn’t work because I’m trying to avoid building inheritance
> hierarchies. I really need something like “friend” (ugly) or the, imo, much
> more elegant file-scoped access and if that one is renamed “fileprivate”
> I’ll be really sad seeing such an ugly label all over the place. I’d go so
> far as to suggest that an ugly name for this access level would actively
> discourage its use and while some might have that as a goal, to me that
> would encourage the creation of larger “do everything” classes instead of
> clusters of smaller classes and structs and protocols.
> >
> > l8r
> > Sean
> >
> > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <
> swift-evolution@swift.org> wrote:
> > >
> > >> 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?
> > >
> > > +1
> > >
> > > Following on from my experience with Delphi adding "strict private"
> for "OO private" members of classes, I would totally agree with your
> proposition.
> > >
> > > Having to use Delphi's "strict private" never really felt right to
> those of us 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

A new type is implicitly internal to a module. Implicitly specifying it as
'external' is just plain confusing.

On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <
swift-evolution@swift.org> wrote:

> I know this is kind of winding down, and there seems to be a kind of
> begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue),
> but I still really don’t like it so I’m going to toss out my current
> favorite configuration and try to stop caring and defer to the core team to
> make an executive decision so we can all move on with our lives. :P
>
> public - unchanged, visible “everywhere"
> external - visible outside of the file (module, the default)
> internal - visible only within the file
> private - visible only within the scope
>
> I really like the existing private and I use it a lot to build collections
> of small classes and structs that work together rather than a large
> class/struct that tries to “be everything”. In those scenarios, traditional
> OO private would be too restrictive and even a “protected” access type
> wouldn’t work because I’m trying to avoid building inheritance hierarchies.
> I really need something like “friend” (ugly) or the, imo, much more elegant
> file-scoped access and if that one is renamed “fileprivate” I’ll be really
> sad seeing such an ugly label all over the place. I’d go so far as to
> suggest that an ugly name for this access level would actively discourage
> its use and while some might have that as a goal, to me that would
> encourage the creation of larger “do everything” classes instead of
> clusters of smaller classes and structs and protocols.
>
> l8r
> Sean
>
> > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> 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?
> >
> > +1
> >
> > Following on from my experience with Delphi adding "strict private" for
> "OO private" members of classes, I would totally agree with your
> proposition.
> >
> > Having to use Delphi's "strict private" never really felt right to those
> of us who were brought up on the OO concept of private, and having
> "private" mean file scope simply encouraged very bad, large, files with
> lots of classes; especially for those who were new to programming.
> >
> > This proposal means that folks coming from other OO languages will
> instantly understand "private"; "fileprivate" does what it says on the tin.
> >
> > To my mind, the only extra scope that might be useful is the OO concept
> of "protected" on a class, but I would like to see a discussion purely
> centred on the effect of more protocols and less class inheritance, with
> its attendant impact on whether protected could also suit extending
> (otherwise private) scope to extensions.
> >
> > In recent experiments of adapting the GOF Design Patterns to Swift, I
> have found using protocols and extensions to greatly reduce the need for
> class inheritance, if not removing the need for classes at all in favour of
> structs.
> >
> > Joanna
> >
> > --
> > Joanna Carter
> > Carter Consulting
> >
> > ___
> > 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Sean Heber via swift-evolution]

I know this is kind of winding down, and there seems to be a kind of begrudging 
acceptance of “fileprivate” emerging (perhaps due to fatigue), but I still 
really don’t like it so I’m going to toss out my current favorite configuration 
and try to stop caring and defer to the core team to make an executive decision 
so we can all move on with our lives. :P

public - unchanged, visible “everywhere"
external - visible outside of the file (module, the default)
internal - visible only within the file
private - visible only within the scope

I really like the existing private and I use it a lot to build collections of 
small classes and structs that work together rather than a large class/struct 
that tries to “be everything”. In those scenarios, traditional OO private would 
be too restrictive and even a “protected” access type wouldn’t work because I’m 
trying to avoid building inheritance hierarchies. I really need something like 
“friend” (ugly) or the, imo, much more elegant file-scoped access and if that 
one is renamed “fileprivate” I’ll be really sad seeing such an ugly label all 
over the place. I’d go so far as to suggest that an ugly name for this access 
level would actively discourage its use and while some might have that as a 
goal, to me that would encourage the creation of larger “do everything” classes 
instead of clusters of smaller classes and structs and protocols.

l8r
Sean

> On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution 
>  wrote:
> 
>> 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?
> 
> +1
> 
> Following on from my experience with Delphi adding "strict private" for "OO 
> private" members of classes, I would totally agree with your proposition.
> 
> Having to use Delphi's "strict private" never really felt right to those of 
> us who were brought up on the OO concept of private, and having "private" 
> mean file scope simply encouraged very bad, large, files with lots of 
> classes; especially for those who were new to programming.
> 
> This proposal means that folks coming from other OO languages will instantly 
> understand "private"; "fileprivate" does what it says on the tin.
> 
> To my mind, the only extra scope that might be useful is the OO concept of 
> "protected" on a class, but I would like to see a discussion purely centred 
> on the effect of more protocols and less class inheritance, with its 
> attendant impact on whether protected could also suit extending (otherwise 
> private) scope to extensions.
> 
> In recent experiments of adapting the GOF Design Patterns to Swift, I have 
> found using protocols and extensions to greatly reduce the need for class 
> inheritance, if not removing the need for classes at all in favour of structs.
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Joanna Carter via swift-evolution]

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

+1

Following on from my experience with Delphi adding "strict private" for "OO 
private" members of classes, I would totally agree with your proposition.

Having to use Delphi's "strict private" never really felt right to those of us 
who were brought up on the OO concept of private, and having "private" mean 
file scope simply encouraged very bad, large, files with lots of classes; 
especially for those who were new to programming.

This proposal means that folks coming from other OO languages will instantly 
understand "private"; "fileprivate" does what it says on the tin.

To my mind, the only extra scope that might be useful is the OO concept of 
"protected" on a class, but I would like to see a discussion purely centred on 
the effect of more protocols and less class inheritance, with its attendant 
impact on whether protected could also suit extending (otherwise private) scope 
to extensions.

In recent experiments of adapting the GOF Design Patterns to Swift, I have 
found using protocols and extensions to greatly reduce the need for class 
inheritance, if not removing the need for classes at all in favour of structs.

Joanna

--
Joanna Carter
Carter Consulting

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

With these names we lose consistency. The current scheme makes it very
clear that each next level is a subset of the previous level. With
"internal", fileprivate looks out of place.

We have several goals for all the names:
1) obvious
2) using standard terms
3) short
4) consistent

This discussion shows that we cannot have all of them. We have to pick
something at the expense of something else.

For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that
with this order

public
moduleprivate
fileprivate
private

is the best so far.

public
internal
fileprivate
private

is not as consistent. It's also not as obvious, given that many people
proposed to use internal to mean fileprivate. The biggest advantages of
these names are that there is less change and short words. If these are the
most important goals, then my original proposal is even better:

public
internal
private
scoped

It's a non-breaking change, everything retains its meaning, the added name
is very clear, and all the names are very short. The biggest problem here
is "private" -- it's not the most private that the language provides, and
most people would expect that.

Here is another one like that (it solves the "private" problem at the
expense of using non-standard terms):

public
internal
local
scoped

My main point is that we cannot have everything. We have to pick the order
of importance.

We heard many times that "short" is not the goal of Swift. Instead, it's
clarity. If this is the case, then I think

public
moduleprivate
fileprivate
private

is the clearest we've seen. Nobody could possibly be confused about the
meaning of these names. I doubt that moduleprivate will be required to
spell out in any style guide, but even so, it's not so bad. We have many
frequently used class names that are much longer.

On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Wallacy via swift-evolution]

I have to say, I'm not very happy with the progress of this topic ..
Let me explain:
I'm Swift user from day 1. A few weeks after, even with the limitations of
language, had an application in production.

One of the "cool" features that regularly use in my application is the
"file private" access level. Is very better (in practice) than C++
friendly, and enable a lot of different manners to think in our code design.

For example: I have a "hand shake" file, wen two specific types extension
knows about specift (and private) functions to do this "hand shake".

So, my problem is, after almost two years using Swift, "public", "internal"
and "private" is just "so obvious" and very easy to understand, change the
"old" private to something else is not very good.

I can understand the need to "more private" than current private, but who
need this feature?
* devs which do not want declare this "important" type in a different file.
* devs which want to declare more than one type per file to make some "
*friendly*" relationship, but not share some other specific information.
* devs which want to declare more than one type per file and *not* make any
relationship with these types different than public.

Also, I'm not expert, but the actual swift access control appear to enable
some good compiler optimizations, and works very well with top level
objects.

So my proposal is:

- *public* (do not change)
- *internal* (do not change)
- *private* (do not change)
- *protect* (new)

Why protect?

*First*, I believe that is a good word to identify a property that will be
accessed in a specific scope.
*Second*, it will only be used when the person declaring more than one type
in a single file and does not want to share any specific property. I think
this person opt to share the same file for more than one type, the "scope"
access control will be less used than current private (file based) because
a think there less "super private" properties between between those types
for the rest of the module.
*Third*, although I believe that Swift not need (and will not get) access
control only to subtypes, simply update this "protect" is enough (task for
another proposal). And even if the protect switch to "also" share
properties between subtypes, only those who want to put all subtypes in the
same file will lose.

Is impossible to make everyone happy anyway... And i think is good choose
the path which "extends" the rationale of the Swift access control over
these two years instead say "file based access control is now not so
important".



Em qui, 31 de mar de 2016 às 01:22, Chris Lattner via swift-evolution <
swift-evolution@swift.org> escreveu:

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matt Whiteside via swift-evolution]

> So, proposal one (and 1b), more technical sounding
> 
> public
> internal (or intramodule)
> intrafile
> private
`intrafile` and `intramodule` sound esoteric to me.

I like these ones better:

public
moduleonly
fileonly
private//aka, scopeonly? unfortunate that this isn’t automatically clear 



Tino’s suggestion is also interesting:

visible(public)
visible(module)
visible(file)
visible(scope)
visible(file, ModuleA, File.swift)

But I think the paren syntax suggested earlier is equivalent, and would be the 
clearest to both experienced and beginning developers:

public
private(module)
private(file)
private(scope)

If parens are a no-go, perhaps the following could work:

public
privatetomodule
privatetofile
privatetoscope

I’m not a huge fan of `fileprivate` or `moduleprivate`, because they seem like 
strange non-words.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Brandon Knope via swift-evolution]

I'd be okay with this, but I do think having a private and fileprivate will 
confuse people considering they both have private in their names

Brandon 

Sent from my iPad

> On Mar 31, 2016, at 12:22 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
> 
> 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
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Michel Fortin via swift-evolution]

Or maybe we could just abolish of file-private. It's not like it'd be 100% 
gone: private declarations at the root of a file will always be equivalent to 
file-private. For non-root things that need to be accessible within the file 
you can use `internal`, which is more accessible than before but still bounded 
to the current module.


> Le 31 mars 2016 à 0:22, Chris Lattner via swift-evolution 
>  a écrit :
> 
> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
> 
> 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
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Pierre Monod-Broca via swift-evolution]

I like :

- public
- modulewide or moduleprivate or internal
- filewide or fileprivate
- private

I really dislike interfile because the word exists and means something else
I dislike intermodule, inmodule and infile because I don't find them intuitive 
at all.

I prefer the -wide flavors because they're shorter than the -private flavors, 
and because -wide is an existing suffix in english.
Internal has the advantage of no modification but if we want to change it, now 
is the time.


> Le 31 mars 2016 à 11:10, Ross O'Brien via swift-evolution 
>  a écrit :
> 
> > public
> > internal
> > interfile
> > private
> 
> Linguistically, I really like this direction. 'interfile' is one word, it 
> reads as an adjective, it can be used in conversation (this has interfile 
> visibility), and it's clear about where its visibility ends.
> 
> It just doesn't mean what you think it means.
> 
> 'inter' means 'between'. See: 'intergalactic', 'interstellar', 
> 'international', 'internet'. So 'interfile' would have to mean 'visible 
> between files' - i.e. an interfile symbol in one file is visible in another 
> file. The prefix you're looking for, meaning 'internal', is 'intra' (see: 
> 'intravenous', 'intranet').
> 
> So the scale would become:
> 
> public / intermodule
> internal / intramodule / interfile
> intrafile
> private
> 
> 
> On Thu, Mar 31, 2016 at 6:04 AM, Paul Ossenbruggen via swift-evolution 
> > wrote:
> public
> internal
> interfile
> private
> 
> still googleable and very clear its scope and meaning, nice latin root. 
> Doesn’t overload “private”, slightly shorter.
> 
> 
> > On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution 
> > > wrote:
> >
> > Looks good to me.
> >
> > -Thorsten
> >
> >> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution 
> >> >:
> >>
> >>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  >>> > 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.
> >>
> >> 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
> >> ___
> >> 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 
> 
> 
> ___
> swift-evolution 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

> public
> internal
> interfile
> private

Linguistically, I really like this direction. 'interfile' is one word, it
reads as an adjective, it can be used in conversation (this has interfile
visibility), and it's clear about where its visibility ends.

It just doesn't mean what you think it means.

'inter' means 'between'. See: 'intergalactic', 'interstellar',
'international', 'internet'. So 'interfile' would have to mean 'visible
between files' - i.e. an interfile symbol in one file is visible in another
file. The prefix you're looking for, meaning 'internal', is 'intra' (see:
'intravenous', 'intranet').

So the scale would become:

public / intermodule
internal / intramodule / interfile
intrafile
private


On Thu, Mar 31, 2016 at 6:04 AM, Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

> public
> internal
> interfile
> private
>
> still googleable and very clear its scope and meaning, nice latin root.
> Doesn’t overload “private”, slightly shorter.
>
>
> > On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Looks good to me.
> >
> > -Thorsten
> >
> >> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution <
> swift-evolution@swift.org>:
> >>
> >>> On Mar 23, 2016, at 10:13 PM, Chris Lattner 
> 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.
> >>
> >> 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
> >> ___
> >> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

If not interfile I can suggest infile again too.

> On Mar 31, 2016, at 12:38 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> 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
> 
> I don't like how this ends up penalizing `fileprivate` with an ugly compound 
> keyword. I feel like, with the way I tend to factor my code, I would continue 
> using it reasonably often, and it would suck to have to use an ugly keyword.
> 
> Consider some of the places where we're still going to need `fileprivate`:
> 
> * Members used by operators or other free functions.
> * Members of nested types meant to be used only by the containing type.
> * Code which splits a type up into extensions. (We want to encourage this.)
> * Code which pairs a type with an extension adding an API using that type to 
> another type. (We want to encourage this too.)
> 
> These are all things we want to encourage, and things where just making them 
> `internal` is going to be tempting. Access control is a delicate thing; using 
> tight access control imposes obvious short-term costs for subtle long-term 
> gains, and so you're always tempted to cheat by making things broader than 
> they should be for your own convenience. The only thing keeping you from 
> cheating is your own discipline.
> 
> I worry that, if `fileprivate` is a long, ugly, obscure, and cumbersome 
> keyword, and `internal` works just as well but requires no typing at all, a 
> lot of people are going to do the wrong thing. We don't want that to happen.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Brent Royal-Gordon via swift-evolution]

> 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

I don't like how this ends up penalizing `fileprivate` with an ugly compound 
keyword. I feel like, with the way I tend to factor my code, I would continue 
using it reasonably often, and it would suck to have to use an ugly keyword.

Consider some of the places where we're still going to need `fileprivate`:

* Members used by operators or other free functions.
* Members of nested types meant to be used only by the containing type.
* Code which splits a type up into extensions. (We want to encourage this.)
* Code which pairs a type with an extension adding an API using that type to 
another type. (We want to encourage this too.)

These are all things we want to encourage, and things where just making them 
`internal` is going to be tempting. Access control is a delicate thing; using 
tight access control imposes obvious short-term costs for subtle long-term 
gains, and so you're always tempted to cheat by making things broader than they 
should be for your own convenience. The only thing keeping you from cheating is 
your own discipline.

I worry that, if `fileprivate` is a long, ugly, obscure, and cumbersome 
keyword, and `internal` works just as well but requires no typing at all, a lot 
of people are going to do the wrong thing. We don't want that to happen.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Hart via swift-evolution]

Perhaps it's because I'm not a native English speaker, but interfile doesn't 
read well at all to me whereas fileprivate is crystal-clear.

> On 31 Mar 2016, at 08:21, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> public
> internal
> (fileprivate | interfile)
> private
> 
> Either choice is fine with me
> 
>> On Thu, Mar 31, 2016 at 11:33 AM, Jesse Squires via swift-evolution 
>>  wrote:
>> I really like this. +1 for the following:
>> 
>> public
>> internal
>> fileprivate
>> private
>> 
>> -Jesse
>> 
>>> On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
>>> 
>>> 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
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
>> -- 
>> Jesse Squires
>> 
>> blog | jessesquires.com
>> github | github.com/jessesquires
>> hexedbits | hexedbits.com
>> 
>> ___
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Hart via swift-evolution]

I love those. And internal corresponds to the meaning it has in other languages.

+1

> On 31 Mar 2016, at 06:22, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
> 
> 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
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[T.J. Usiyan via swift-evolution]

public
internal
(fileprivate | interfile)
private

Either choice is fine with me

On Thu, Mar 31, 2016 at 11:33 AM, Jesse Squires via swift-evolution <
swift-evolution@swift.org> wrote:

> I really like this. +1 for the following:
>
> public
> internal
> fileprivate
> private
>
> -Jesse
>
> On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
>>
>> 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
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
> --
> Jesse Squires
>
> *blog* | jessesquires.com 
> *github* | github.com/jessesquires 
> *hexedbits* | hexedbits.com 
>
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jesse Squires via swift-evolution]

I really like this. +1 for the following:

public
internal
fileprivate
private

-Jesse

On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
>
> 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
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Jesse Squires

*blog* | jessesquires.com 
*github* | github.com/jessesquires 
*hexedbits* | hexedbits.com 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

One bonus it is a real word so autocorrect doesn’t fix it! I checked the 
dictionary and there are no negative or misleading meaning. 

It is a verb though, this is not being used as a verb in this case. 

http://www.dictionary.com/browse/interfile 


> On Mar 30, 2016, at 10:04 PM, Paul Ossenbruggen  wrote:
> 
> public
> internal
> interfile
> private
> 
> still googleable and very clear its scope and meaning, nice latin root. 
> Doesn’t overload “private”, slightly shorter. 
> 
> 
>> On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> Looks good to me.
>> 
>> -Thorsten 
>> 
>>> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution 
>>> :
>>> 
 On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
>>> 
>>> 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
>>> ___
>>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Thorsten Seitz via swift-evolution]

Looks good to me.

-Thorsten 

> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution 
> :
> 
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner  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.
> 
> 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
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Chris Lattner via swift-evolution]

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

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

One more possibility:

public
intermodule
interfile 
private

slightly longer but reads well.

> On Mar 30, 2016, at 9:11 PM, Paul Ossenbruggen  wrote:
> 
> Ok speaking up, not a fan of fileprivate and moduleprivate because 
> 
> 1) very long
> 2) doesn’t flow. 
> 3) not really private. 
> 
> I would be fine with filewide and modulewide and infile and inmodule with a 
> slight preference for the infile and inmodule because it is shorter and 
> conveys the same meaning and flows about the same. 
> 
>> I still prefer the latter ones, but I wonder if -wide ones will be a happier 
>> compromise? Those unhappy with xxxprivate, please speak up!
>> 
>> A.
>> 
> 

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

Ok speaking up, not a fan of fileprivate and moduleprivate because 

1) very long
2) doesn’t flow. 
3) not really private. 

I would be fine with filewide and modulewide and infile and inmodule with a 
slight preference for the infile and inmodule because it is shorter and conveys 
the same meaning and flows about the same. 

> I still prefer the latter ones, but I wonder if -wide ones will be a happier 
> compromise? Those unhappy with xxxprivate, please speak up!
> 
> A.
> 

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Andrey Tarantsov via swift-evolution]

> public
> filewide 
> modulewide 
> private
> 
> Don’t bother me because they seem to be part of the word. The way 
> “nationwide” does, they are made up words but intent is clear.

I could live with filewide and modulewide instead of fileprivate and 
moduleprivate.

I still prefer the latter ones, but I wonder if -wide ones will be a happier 
compromise? Those unhappy with xxxprivate, please speak up!

A.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

public
filewide 
modulewide 
private

Don’t bother me because they seem to be part of the word. The way “nationwide” 
does, they are made up words but intent is clear.

OK violating my own statement of only having single words, but very short 
words. How about?

public 
inmodule
infile
private
 
I think this is good too.

> * public
> * moduleinternal
> * internal
> * private

people who insist on always specifying access will either live with it or make 
one exception. 

> On Mar 30, 2016, at 6:47 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I know that it’s been suggested a while back, but what is/was the reasoning 
>> for rejecting:
>> 
>>  • public
>>  • module (same as internal in Swift 2.2)
>>  • file (same as private in Swift 2.2)
>>  • private
> 
> I know; I was one of the people who suggested it. I believe I saw two reasons 
> for rejecting it:
> 
> 1. This might be read as declaring a module/file, or attaching it to a 
> module/file (a la `class func`), rather than scoping it.
> 2. `private` and `public` are adjectives; `module` and `file` are nouns.
> 
> I'm not entirely convinced by #1; #2 could be addressed by using, for 
> instance, `modulewide` and `filewide`. In any case, though, the discussion 
> seems to have moved elsewhere.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Waite via swift-evolution]

I wonder if perhaps it would be clearer if public was used for indicating 
something was published, even if it is published to a restricted set:

public(#all)- expose outside the framework, shortened to public
public(#module) - exposed module-wide, default if omitted
public(#file)   - expose to other code within the file
private - not exposed outside lexical scope

named contexts such as a particular type or other module would be possible in 
the future via non-# names, and multiple contexts could be possible in the 
future via comma-separated values

-DW

> On Mar 30, 2016, at 7:24 PM, Matthew Judge via swift-evolution 
>  wrote:
> 
> Some other module name would seem to suggest "public(scope-name)"
> 
> I agree "private(scope-name)" should only be used to disambiguate between the 
> concentric scope circles (if I declare something in the main class it is 
> visible in the main class declaration scope, the file scope, and the module 
> scope... And I can declare something private to any of those scopes).
> 
> On Mar 30, 2016, at 15:39, Jordan Rose via swift-evolution 
> > wrote:
> 
>> Ah, sorry! Those are all clear to me; it's the possibility of writing some 
>> other module name there that would have the wrong implications.
>> 
>> Jordan
>> 
>>> On Mar 30, 2016, at 12:38 , Ross O'Brien >> > wrote:
>>> 
>>> Damn, and I thought it was clear all this time that 'private(module)', or 
>>> 'private(#module)', or 'moduleprivate', meant that the symbol is visible 
>>> only inside the module. It's always been a suggested replacement specifier 
>>> for 'internal'.
>>> 
>>> On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
 On Mar 29, 2016, at 17:47 , Brent Royal-Gordon > wrote:
 
> If Scala style access modifiers were adopted for Swift then a 
> private(file) modifier would also be necessary to give the current 
> private functionality.
 
 I could imagine having these options:
 
public  // visible to 
 all everyone
private(scope-name, scope-name, …)  // visible to specified scopes 
 (plus current scope)
private // visible only 
 to current scope
 
 scope-name could perhaps be:
 
 * A type name (or Self, which would mimic C++-style private, or perhaps 
 even C++-style protected depending on how we treat inheritance)
 * A module name (or #module for the current module)
 * A file name string (or #file for the current file)
 
 And then the default would simply be `private(#module)`.
 
 Alternatively, the parameterized level could be given a different name, 
 like `internal` or `shared`. If that were the case, then `#module` might 
 simply be the default.
>>> 
>>> I've actually thought about this before (well, at least at the module 
>>> level) and ultimately decided it was a bad idea for it to be part of the 
>>> access control system. Why? Because there's nothing "private" about sharing 
>>> with another module, even if it's just one other module.
>>> 
>>> - You don't get any secrecy because you have to publish all symbols and 
>>> metadata as public.
>>> - You can't optimize based on knowledge of how the declaration is used.
>>> - Exposing something to another module can be viral, just like making 
>>> something 'public' would be viral: all of a type's protocol conformances 
>>> are exposed, a class's superclass must be exposed, all the types in a 
>>> function signature have to be exposed (or already public).
>>> 
>>> All of this means that this behaves more like "public" than like "private"; 
>>> it's "public, but not the entire public". The restriction on use sites is 
>>> an artificial one.
>>> 
>>> Now, it is a very useful feature! Apple, of course, does this all the time 
>>> with its "SPI". But I think the right form of the feature is to be able to 
>>> tag a bunch of public declarations as "SPI" or "limited" or "limited to 
>>> group 'X'" or possibly even "limited to module 'X'", and then have a tool 
>>> to strip them out of the swiftmodule file when you're ready to ship this 
>>> module to people. That way you're enforcing your limitations as much as 
>>> possible, while still using the same binaries for both internal and 
>>> external clients. (Remember that the swiftmodule file serves essentially 
>>> the same purpose as header files in C.)
>>> 
>>> 
>>> At the file level, there's nothing inherently wrong with this idea, but I 
>>> don't think there's enough gain to writing file strings directly in source 
>>> files. Pointing to a future 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Michael Wells via swift-evolution]

I know that it’s been suggested a while back, but what is/was the reasoning for 
rejecting:

public
module (same as internal in Swift 2.2)
file (same as private in Swift 2.2)
private

It seems pretty simple, clear, and understandable. It doesn’t make itself very 
useful as search terms (module or file are pretty generic), but I would assume 
that would be a learn-once-and-your-done thing.
—
Michael Wells


> On Mar 30, 2016, at 5:24 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I maintain that anyone with a coding convention of "always write an access 
>> modifier" will be very upset with this.
> 
> I doubt they'll be too pleased with `moduleprivate`, either.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

> On Mar 30, 2016, at 16:30, Brent Royal-Gordon  wrote:
> 
> While working that out, I also came up with a new suggestion for keywording 
> if we keep just these four levels and don't generalize `fileprivate` into an 
> "internal, with limitations" mechanism:
> 
> * public
> * moduleinternal
> * internal
> * private
> 
> This version saddles only the module access level, which rarely needs to be 
> typed explicitly, with an awkward compound keyword. The file access level 
> (which I suspect is more often necessary than many in this thread believe) 
> gets a single, simple keyword. Additionally, by having only one gobbledygook 
> access level, when you *do* see the gobbledygook keyword you don't have to 
> try to parse it.
> 
> This does have the disadvantage of not matching C#'s meaning of `internal`; 
> we could do something else, like `shared`/`moduleshared`, instead. But I'm 
> not sure how valuable that correspondence is.

I maintain that anyone with a coding convention of "always write an access 
modifier" will be very upset with this.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

> On Mar 30, 2016, at 15:20, Brent Royal-Gordon  wrote:
> 
>> Now, it is a very useful feature! Apple, of course, does this all the time 
>> with its "SPI". But I think the right form of the feature is to be able to 
>> tag a bunch of public declarations as "SPI" or "limited" or "limited to 
>> group 'X'" or possibly even "limited to module 'X'", and then have a tool to 
>> strip them out of the swiftmodule file when you're ready to ship this module 
>> to people. That way you're enforcing your limitations as much as possible, 
>> while still using the same binaries for both internal and external clients. 
>> (Remember that the swiftmodule file serves essentially the same purpose as 
>> header files in C.)
> 
> Actually, I can think of one very interesting boundary that roughly parallels 
> the SPI/API boundary: the boundary between resilience domains. In other 
> words, "public within resilience domain" may be a useful access level.
> 
> However, that obviously is not the same as exposing to different modules. I 
> understand why you might not think that's a good idea.

Hm. That may indeed be useful because it allows the compiler to omit resilient 
information about the declaration. I'm worried that's just adding more knobs 
that won't really be a benefit in practice, though.

(For anyone wondering what this is, it's part of the very long design document 
for future "Library Evolution Support in Swift 
".)


> 
>> At the file level, there's nothing inherently wrong with this idea, but I 
>> don't think there's enough gain to writing file strings directly in source 
>> files. Pointing to a future "comprehensive submodules model" would be 
>> disingenuous because that's a huge feature with a lot of subtlety, but I 
>> think "just make this accessible to one other file" is additional complexity 
>> for not much gain. It's also subject to slippery-slope: once one file is 
>> added, I don't think anyone would think too hard about adding a second file, 
>> and then…
> 
> It does offer a solution to the stored property problem (because you can only 
> define stored properties in the type's main definition, all stored properties 
> must be able to see each others' private state); you could put each extension 
> in a separate file and then expose the relevant stored properties only to the 
> file for the extension that needs it. But I do understand why you might not 
> like that idea; there is a certain smell associated with embedding source 
> file names in your code.
> 
> Mostly, it just bothers me that we have these two middle access levels 
> (`moduleprivate` and `fileprivate`) which seem closely related compared to 
> new-`private`, yet are both completely ad-hoc and elude decent naming. 
> Calling them, say, `internal` and having `internal(#file)` be a special case 
> of `internal(file names here)` seems like a nice way to rationalize them.

Can you elaborate on why "moduleprivate" and "fileprivate" are closely related 
for you? To me all three of the proposed non-public levels are "concentric 
circles"; one of them is bounded by braces, one by the filesystem, and one by 
the files in your target (as described by Xcode or the package manager or an ad 
hoc build).

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Brent Royal-Gordon via swift-evolution]

> Now, it is a very useful feature! Apple, of course, does this all the time 
> with its "SPI". But I think the right form of the feature is to be able to 
> tag a bunch of public declarations as "SPI" or "limited" or "limited to group 
> 'X'" or possibly even "limited to module 'X'", and then have a tool to strip 
> them out of the swiftmodule file when you're ready to ship this module to 
> people. That way you're enforcing your limitations as much as possible, while 
> still using the same binaries for both internal and external clients. 
> (Remember that the swiftmodule file serves essentially the same purpose as 
> header files in C.)

Actually, I can think of one very interesting boundary that roughly parallels 
the SPI/API boundary: the boundary between resilience domains. In other words, 
"public within resilience domain" may be a useful access level.

However, that obviously is not the same as exposing to different modules. I 
understand why you might not think that's a good idea.

> At the file level, there's nothing inherently wrong with this idea, but I 
> don't think there's enough gain to writing file strings directly in source 
> files. Pointing to a future "comprehensive submodules model" would be 
> disingenuous because that's a huge feature with a lot of subtlety, but I 
> think "just make this accessible to one other file" is additional complexity 
> for not much gain. It's also subject to slippery-slope: once one file is 
> added, I don't think anyone would think too hard about adding a second file, 
> and then…

It does offer a solution to the stored property problem (because you can only 
define stored properties in the type's main definition, all stored properties 
must be able to see each others' private state); you could put each extension 
in a separate file and then expose the relevant stored properties only to the 
file for the extension that needs it. But I do understand why you might not 
like that idea; there is a certain smell associated with embedding source file 
names in your code.

Mostly, it just bothers me that we have these two middle access levels 
(`moduleprivate` and `fileprivate`) which seem closely related compared to 
new-`private`, yet are both completely ad-hoc and elude decent naming. Calling 
them, say, `internal` and having `internal(#file)` be a special case of 
`internal(file names here)` seems like a nice way to rationalize them.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Howard Lovatt via swift-evolution]

How about public, private, private(#file), and private(#module)? At a later
date, if needed, private(S1, S3, ...) could be added. This would be a
minimal change and not stop an extension in the future if requested.

On Thursday, 31 March 2016, James Campbell via swift-evolution <
swift-evolution@swift.org> wrote:

> What about local for a file only or scope definition ?
>
> Sent from Supmenow.com 
>
>
>
>
> On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution"
>  > wrote:
>
> Ah, sorry! Those are all clear to me; it's the possibility of writing some
>> *other* module name there that would have the wrong implications.
>>
>> Jordan
>>
>> On Mar 30, 2016, at 12:38 , Ross O'Brien > > wrote:
>>
>> Damn, and I thought it was clear all this time that 'private(module)', or
>> 'private(#module)', or 'moduleprivate', meant that the symbol is visible
>> only inside the module. It's always been a suggested replacement specifier
>> for 'internal'.
>>
>> On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution <
>> swift-evolution@swift.org
>> > wrote:
>>
>>>
>>> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon >> > wrote:
>>>
>>> If Scala style access modifiers were adopted for Swift then a
>>> private(file) modifier would also be necessary to give the current private
>>> functionality.
>>>
>>>
>>> I could imagine having these options:
>>>
>>> public // visible to all everyone
>>> private(scope-name, scope-name, …) // visible to specified scopes (plus
>>> current scope)
>>> private // visible only to current scope
>>>
>>> scope-name could perhaps be:
>>>
>>> * A type name (or Self, which would mimic C++-style private, or perhaps
>>> even C++-style protected depending on how we treat inheritance)
>>> * A module name (or #module for the current module)
>>> * A file name string (or #file for the current file)
>>>
>>> And then the default would simply be `private(#module)`.
>>>
>>> Alternatively, the parameterized level could be given a different name,
>>> like `internal` or `shared`. If that were the case, then `#module` might
>>> simply be the default.
>>>
>>>
>>> I've actually thought about this before (well, at least at the module
>>> level) and ultimately decided it was a bad idea for it to be part of the
>>> access control system. Why? Because there's nothing "private" about sharing
>>> with another module, even if it's just *one* other module.
>>>
>>> - You don't get any secrecy because you have to publish all symbols and
>>> metadata as public.
>>> - You can't optimize based on knowledge of how the declaration is used.
>>> - Exposing something to another module can be viral, just like making
>>> something 'public' would be viral: all of a type's protocol conformances
>>> are exposed, a class's superclass must be exposed, all the types in a
>>> function signature have to be exposed (or already public).
>>>
>>> All of this means that this behaves more like "public" than like
>>> "private"; it's "public, but not the *entire* public". The restriction
>>> on use sites is an artificial one.
>>>
>>> Now, it *is* a very useful feature! Apple, of course, does this all the
>>> time with its "SPI". But I think the right form of the feature is to be
>>> able to tag a bunch of public declarations as "SPI" or "limited" or
>>> "limited to group 'X'" or possibly even "limited to module 'X'", and then
>>> have a tool to *strip them out* of the swiftmodule file when you're
>>> ready to ship this module to people. That way you're enforcing your
>>> limitations as much as possible, while still using the same binaries for
>>> both internal and external clients. (Remember that the swiftmodule file
>>> serves essentially the same purpose as header files in C.)
>>>
>>>
>>> At the file level, there's nothing inherently wrong with this idea, but
>>> I don't think there's enough gain to writing file strings directly in
>>> source files. Pointing to a future "comprehensive submodules model" would
>>> be disingenuous because that's a *huge* feature with a lot of subtlety,
>>> but I think "just make this accessible to one other file" is additional
>>> complexity for not much gain. It's also subject to slippery-slope: once one
>>> file is added, I don't think anyone would think too hard about adding a
>>> *second* file, and then…
>>>
>>> Jordan
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>

-- 
-- Howard.
___
swift-evolution mailing 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[James Campbell via swift-evolution]

What about local for a file only or scope definition ? 

Sent from Supmenow.com




On Wed, Mar 30, 2016 at 12:39 PM -0700, "Jordan Rose via swift-evolution" 
 wrote:










Ah, sorry! Those are all clear to me; it's the possibility of writing some 
other module name there that would have the wrong implications.
Jordan
On Mar 30, 2016, at 12:38 , Ross O'Brien  wrote:
Damn, and I thought it was clear all this time that 'private(module)', or 
'private(#module)', or 'moduleprivate', meant that the symbol is visible only 
inside the module. It's always been a suggested replacement specifier for 
'internal'.
On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution 
 wrote:

On Mar 29, 2016, at 17:47 , Brent Royal-Gordon  wrote:
If Scala style access modifiers were adopted for Swift then a private(file) 
modifier would also be necessary to give the current private functionality.

I could imagine having these options:

public  // visible to 
all everyone
private(scope-name, scope-name, …)  // visible to specified scopes 
(plus current scope)
private // visible only 
to current scope

scope-name could perhaps be:

* A type name (or Self, which would mimic C++-style private, or perhaps even 
C++-style protected depending on how we treat inheritance)
* A module name (or #module for the current module)
* A file name string (or #file for the current file)

And then the default would simply be `private(#module)`.

Alternatively, the parameterized level could be given a different name, like 
`internal` or `shared`. If that were the case, then `#module` might simply be 
the default.

I've actually thought about this before (well, at least at the module level) 
and ultimately decided it was a bad idea for it to be part of the access 
control system. Why? Because there's nothing "private" about sharing with 
another module, even if it's just one other module.
- You don't get any secrecy because you have to publish all symbols and 
metadata as public.- You can't optimize based on knowledge of how the 
declaration is used.- Exposing something to another module can be viral, just 
like making something 'public' would be viral: all of a type's protocol 
conformances are exposed, a class's superclass must be exposed, all the types 
in a function signature have to be exposed (or already public).
All of this means that this behaves more like "public" than like "private"; 
it's "public, but not the entire public". The restriction on use sites is an 
artificial one.
Now, it is a very useful feature! Apple, of course, does this all the time with 
its "SPI". But I think the right form of the feature is to be able to tag a 
bunch of public declarations as "SPI" or "limited" or "limited to group 'X'" or 
possibly even "limited to module 'X'", and then have a tool to strip them out 
of the swiftmodule file when you're ready to ship this module to people. That 
way you're enforcing your limitations as much as possible, while still using 
the same binaries for both internal and external clients. (Remember that the 
swiftmodule file serves essentially the same purpose as header files in C.)

At the file level, there's nothing inherently wrong with this idea, but I don't 
think there's enough gain to writing file strings directly in source files. 
Pointing to a future "comprehensive submodules model" would be disingenuous 
because that's a huge feature with a lot of subtlety, but I think "just make 
this accessible to one other file" is additional complexity for not much gain. 
It's also subject to slippery-slope: once one file is added, I don't think 
anyone would think too hard about adding a second file, and then…
Jordan
___

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

Ah, sorry! Those are all clear to me; it's the possibility of writing some 
other module name there that would have the wrong implications.

Jordan

> On Mar 30, 2016, at 12:38 , Ross O'Brien  wrote:
> 
> Damn, and I thought it was clear all this time that 'private(module)', or 
> 'private(#module)', or 'moduleprivate', meant that the symbol is visible only 
> inside the module. It's always been a suggested replacement specifier for 
> 'internal'.
> 
> On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution 
> > wrote:
> 
>> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon > > wrote:
>> 
>>> If Scala style access modifiers were adopted for Swift then a private(file) 
>>> modifier would also be necessary to give the current private functionality.
>> 
>> I could imagine having these options:
>> 
>>  public  // visible to 
>> all everyone
>>  private(scope-name, scope-name, …)  // visible to specified scopes 
>> (plus current scope)
>>  private // visible only 
>> to current scope
>> 
>> scope-name could perhaps be:
>> 
>> * A type name (or Self, which would mimic C++-style private, or perhaps even 
>> C++-style protected depending on how we treat inheritance)
>> * A module name (or #module for the current module)
>> * A file name string (or #file for the current file)
>> 
>> And then the default would simply be `private(#module)`.
>> 
>> Alternatively, the parameterized level could be given a different name, like 
>> `internal` or `shared`. If that were the case, then `#module` might simply 
>> be the default.
> 
> I've actually thought about this before (well, at least at the module level) 
> and ultimately decided it was a bad idea for it to be part of the access 
> control system. Why? Because there's nothing "private" about sharing with 
> another module, even if it's just one other module.
> 
> - You don't get any secrecy because you have to publish all symbols and 
> metadata as public.
> - You can't optimize based on knowledge of how the declaration is used.
> - Exposing something to another module can be viral, just like making 
> something 'public' would be viral: all of a type's protocol conformances are 
> exposed, a class's superclass must be exposed, all the types in a function 
> signature have to be exposed (or already public).
> 
> All of this means that this behaves more like "public" than like "private"; 
> it's "public, but not the entire public". The restriction on use sites is an 
> artificial one.
> 
> Now, it is a very useful feature! Apple, of course, does this all the time 
> with its "SPI". But I think the right form of the feature is to be able to 
> tag a bunch of public declarations as "SPI" or "limited" or "limited to group 
> 'X'" or possibly even "limited to module 'X'", and then have a tool to strip 
> them out of the swiftmodule file when you're ready to ship this module to 
> people. That way you're enforcing your limitations as much as possible, while 
> still using the same binaries for both internal and external clients. 
> (Remember that the swiftmodule file serves essentially the same purpose as 
> header files in C.)
> 
> 
> At the file level, there's nothing inherently wrong with this idea, but I 
> don't think there's enough gain to writing file strings directly in source 
> files. Pointing to a future "comprehensive submodules model" would be 
> disingenuous because that's a huge feature with a lot of subtlety, but I 
> think "just make this accessible to one other file" is additional complexity 
> for not much gain. It's also subject to slippery-slope: once one file is 
> added, I don't think anyone would think too hard about adding a second file, 
> and then…
> 
> Jordan
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

Damn, and I thought it was clear all this time that 'private(module)', or
'private(#module)', or 'moduleprivate', meant that the symbol is visible
only inside the module. It's always been a suggested replacement specifier
for 'internal'.

On Wed, Mar 30, 2016 at 6:33 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon 
> wrote:
>
> If Scala style access modifiers were adopted for Swift then a
> private(file) modifier would also be necessary to give the current private
> functionality.
>
>
> I could imagine having these options:
>
> public // visible to all everyone
> private(scope-name, scope-name, …) // visible to specified scopes (plus
> current scope)
> private // visible only to current scope
>
> scope-name could perhaps be:
>
> * A type name (or Self, which would mimic C++-style private, or perhaps
> even C++-style protected depending on how we treat inheritance)
> * A module name (or #module for the current module)
> * A file name string (or #file for the current file)
>
> And then the default would simply be `private(#module)`.
>
> Alternatively, the parameterized level could be given a different name,
> like `internal` or `shared`. If that were the case, then `#module` might
> simply be the default.
>
>
> I've actually thought about this before (well, at least at the module
> level) and ultimately decided it was a bad idea for it to be part of the
> access control system. Why? Because there's nothing "private" about sharing
> with another module, even if it's just *one* other module.
>
> - You don't get any secrecy because you have to publish all symbols and
> metadata as public.
> - You can't optimize based on knowledge of how the declaration is used.
> - Exposing something to another module can be viral, just like making
> something 'public' would be viral: all of a type's protocol conformances
> are exposed, a class's superclass must be exposed, all the types in a
> function signature have to be exposed (or already public).
>
> All of this means that this behaves more like "public" than like
> "private"; it's "public, but not the *entire* public". The restriction on
> use sites is an artificial one.
>
> Now, it *is* a very useful feature! Apple, of course, does this all the
> time with its "SPI". But I think the right form of the feature is to be
> able to tag a bunch of public declarations as "SPI" or "limited" or
> "limited to group 'X'" or possibly even "limited to module 'X'", and then
> have a tool to *strip them out* of the swiftmodule file when you're ready
> to ship this module to people. That way you're enforcing your limitations
> as much as possible, while still using the same binaries for both internal
> and external clients. (Remember that the swiftmodule file serves
> essentially the same purpose as header files in C.)
>
>
> At the file level, there's nothing inherently wrong with this idea, but I
> don't think there's enough gain to writing file strings directly in source
> files. Pointing to a future "comprehensive submodules model" would be
> disingenuous because that's a *huge* feature with a lot of subtlety, but
> I think "just make this accessible to one other file" is additional
> complexity for not much gain. It's also subject to slippery-slope: once one
> file is added, I don't think anyone would think too hard about adding a
> *second* file, and then…
>
> Jordan
>
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

> On Mar 29, 2016, at 17:47 , Brent Royal-Gordon  wrote:
> 
>> If Scala style access modifiers were adopted for Swift then a private(file) 
>> modifier would also be necessary to give the current private functionality.
> 
> I could imagine having these options:
> 
>   public  // visible to 
> all everyone
>   private(scope-name, scope-name, …)  // visible to specified scopes 
> (plus current scope)
>   private // visible only 
> to current scope
> 
> scope-name could perhaps be:
> 
> * A type name (or Self, which would mimic C++-style private, or perhaps even 
> C++-style protected depending on how we treat inheritance)
> * A module name (or #module for the current module)
> * A file name string (or #file for the current file)
> 
> And then the default would simply be `private(#module)`.
> 
> Alternatively, the parameterized level could be given a different name, like 
> `internal` or `shared`. If that were the case, then `#module` might simply be 
> the default.

I've actually thought about this before (well, at least at the module level) 
and ultimately decided it was a bad idea for it to be part of the access 
control system. Why? Because there's nothing "private" about sharing with 
another module, even if it's just one other module.

- You don't get any secrecy because you have to publish all symbols and 
metadata as public.
- You can't optimize based on knowledge of how the declaration is used.
- Exposing something to another module can be viral, just like making something 
'public' would be viral: all of a type's protocol conformances are exposed, a 
class's superclass must be exposed, all the types in a function signature have 
to be exposed (or already public).

All of this means that this behaves more like "public" than like "private"; 
it's "public, but not the entire public". The restriction on use sites is an 
artificial one.

Now, it is a very useful feature! Apple, of course, does this all the time with 
its "SPI". But I think the right form of the feature is to be able to tag a 
bunch of public declarations as "SPI" or "limited" or "limited to group 'X'" or 
possibly even "limited to module 'X'", and then have a tool to strip them out 
of the swiftmodule file when you're ready to ship this module to people. That 
way you're enforcing your limitations as much as possible, while still using 
the same binaries for both internal and external clients. (Remember that the 
swiftmodule file serves essentially the same purpose as header files in C.)


At the file level, there's nothing inherently wrong with this idea, but I don't 
think there's enough gain to writing file strings directly in source files. 
Pointing to a future "comprehensive submodules model" would be disingenuous 
because that's a huge feature with a lot of subtlety, but I think "just make 
this accessible to one other file" is additional complexity for not much gain. 
It's also subject to slippery-slope: once one file is added, I don't think 
anyone would think too hard about adding a second file, and then…

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

Associatedtype won’t be used nearly as often as these operators, I support the 
rational there but not in this case as it will be seen far more often. 

- Paul
> On Mar 30, 2016, at 8:28 AM, Ilya Belenkiy  wrote:
> 
> I understand. The same is true about associatedtype. My iPhone just suggested 
> it as a one word completion! I think the same will happen with these names. 
> Chris Lattner already described the rationale in this thread, so I won't 
> repeat it. I also originally wanted short names, but I think that we ended  
> up with a good compromise (crystal clear, searchable keywords  that are 
> consistent with other keywords). 
> 
> On Wed, Mar 30, 2016 at 10:54 AM Paul Ossenbruggen  > wrote:
> I understand the desire to wrap this up as it has gone on for a long time.
> 
> I just don’t like the length and readability of the moduleprivate and 
> fileprivate names (and how auto correct is always “fixing” it for me when I 
> try to write about it). As I mentioned these will likely be used very often 
> in code and just don’t look very nice. These are potentially used on almost 
> every method, class, property and struct. I don’t think that we should use 
> something that is perhaps a little clearer in meaning but hard to read for 
> something that is used so frequently through the code. There are plenty of 
> places where you have to look something up the first time you encounter it in 
> any programming language and this explicitness is not a big enough win to 
> sacrifice readability. A single word keyword is a requirement for me. 
> 
> 
>  
>> On Mar 30, 2016, at 6:13 AM, Ilya Belenkiy via swift-evolution 
>> > wrote:
>> 
>> I am not sure if we will ever get another access level. If we do, great, but 
>> given how long this discussion has been already, I am not counting on it :-)
>> 
>> Most likely, if we get more, it will be possible to describe it with a 
>> simple word, or a combination of words or with some common abbreviations, so 
>> I am not worried about extensibility. I think that the names in the proposal 
>> are very consistent with Swift as it is today and will serve us well. They 
>> are also completely unambiguous and don't depend on the reading context, so 
>> if we come up with other ways to label access levels, it should still be 
>> possible to either use these names for backward compatibility or migrate 
>> them automatically to new names without any difference in semantics.
>> 
>> We also needed to pick something. I waited for about a week to get 
>> everybody's vote, and I think that I picked a compromise that we can all be 
>> at least ok with. (I also originally wanted short single word names). I 
>> think we should close the naming thread at this point.
>> On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge > > wrote:
>> 
>> 
>> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>> >> If Scala style access modifiers were adopted for Swift then a 
>> >> private(file) modifier would also be necessary to give the current 
>> >> private functionality.
>> >
>> > I could imagine having these options:
>> >
>> >public// visible to all everyone
>> >private(scope-name, scope-name, …)// visible to specified scopes 
>> > (plus current scope)
>> >private// visible only to current scope
>> >
>> 
>> Allowing multiple "scope-name"s is a lot of flexibility and power, but not 
>> sure it's useful/worthwhile.
>> 
>>  For the current discussion, I would think "scope-name" should be limited to 
>> an enclosing scope only.  So you can say "private(Outer)" from an Inner 
>> class or "private(#file)" from within a class, but not "private(ClassA)" 
>> from within ClassB.
>> 
>> (This would also solve the ambiguity of how to reference the main ClassA or 
>> a specific extension to ClassA... "private(ClassA)" can only refer to 
>> whichever scope of ClassA you are currently in.)
>> 
>> > scope-name could perhaps be:
>> >
>> > * A type name (or Self, which would mimic C++-style private, or perhaps 
>> > even C++-style protected depending on how we treat inheritance)
>> 
>> But, this is getting into type-based access which is beyond the scope of 
>> SE-0025 right?
>> 
>> > * A module name (or #module for the current module)
>> > * A file name string (or #file for the current file)
>> >
>> > And then the default would simply be `private(#module)`.
>> >
>> > Alternatively, the parameterized level could be given a different name, 
>> > like `internal` or `shared`. If that were the case, then `#module` might 
>> > simply be the default.
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> > ___
>> > 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

I understand. The same is true about associatedtype. My iPhone just
suggested it as a one word completion! I think the same will happen with
these names. Chris Lattner already described the rationale in this thread,
so I won't repeat it. I also originally wanted short names, but I think
that we ended up with a good compromise (crystal clear, searchable keywords
that are consistent with other keywords).

On Wed, Mar 30, 2016 at 10:54 AM Paul Ossenbruggen  wrote:

> I understand the desire to wrap this up as it has gone on for a long time.
>
> I just don’t like the length and readability of the moduleprivate and
> fileprivate names (and how auto correct is always “fixing” it for me when I
> try to write about it). As I mentioned these will likely be used very often
> in code and just don’t look very nice. These are potentially used on almost
> every method, class, property and struct. I don’t think that we should use
> something that is perhaps a little clearer in meaning but hard to read for
> something that is used so frequently through the code. There are plenty of
> places where you have to look something up the first time you encounter it
> in any programming language and this explicitness is not a big enough win
> to sacrifice readability. A single word keyword is a requirement for me.
>
>
>
>
> On Mar 30, 2016, at 6:13 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I am not sure if we will ever get another access level. If we do, great,
> but given how long this discussion has been already, I am not counting on
> it :-)
>
> Most likely, if we get more, it will be possible to describe it with a
> simple word, or a combination of words or with some common abbreviations,
> so I am not worried about extensibility. I think that the names in the
> proposal are very consistent with Swift as it is today and will serve us
> well. They are also completely unambiguous and don't depend on the reading
> context, so if we come up with other ways to label access levels, it should
> still be possible to either use these names for backward compatibility or
> migrate them automatically to new names without any difference in semantics.
>
> We also needed to pick something. I waited for about a week to get
> everybody's vote, and I think that I picked a compromise that we can all be
> at least ok with. (I also originally wanted short single word names). I
> think we should close the naming thread at this point.
> On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge 
> wrote:
>
>>
>>
>> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> >> If Scala style access modifiers were adopted for Swift then a
>> private(file) modifier would also be necessary to give the current private
>> functionality.
>> >
>> > I could imagine having these options:
>> >
>> >public// visible to all everyone
>> >private(scope-name, scope-name, …)// visible to specified scopes
>> (plus current scope)
>> >private// visible only to current scope
>> >
>>
>> Allowing multiple "scope-name"s is a lot of flexibility and power, but
>> not sure it's useful/worthwhile.
>>
>>  For the current discussion, I would think "scope-name" should be limited
>> to an enclosing scope only.  So you can say "private(Outer)" from an Inner
>> class or "private(#file)" from within a class, but not "private(ClassA)"
>> from within ClassB.
>>
>> (This would also solve the ambiguity of how to reference the main ClassA
>> or a specific extension to ClassA... "private(ClassA)" can only refer to
>> whichever scope of ClassA you are currently in.)
>>
>> > scope-name could perhaps be:
>> >
>> > * A type name (or Self, which would mimic C++-style private, or perhaps
>> even C++-style protected depending on how we treat inheritance)
>>
>> But, this is getting into type-based access which is beyond the scope of
>> SE-0025 right?
>>
>> > * A module name (or #module for the current module)
>> > * A file name string (or #file for the current file)
>> >
>> > And then the default would simply be `private(#module)`.
>> >
>> > Alternatively, the parameterized level could be given a different name,
>> like `internal` or `shared`. If that were the case, then `#module` might
>> simply be the default.
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> > ___
>> > 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

The scala idea is interesting, has anyone used it extensively to understand how 
well it works in practice? Is it too fiddly? Do you spend too much time 
thinking about access levels. 

> On Mar 29, 2016, at 5:47 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> If Scala style access modifiers were adopted for Swift then a private(file) 
>> modifier would also be necessary to give the current private functionality.
> 
> I could imagine having these options:
> 
>   public  // visible to 
> all everyone
>   private(scope-name, scope-name, …)  // visible to specified scopes 
> (plus current scope)
>   private // visible only 
> to current scope
> 
> scope-name could perhaps be:
> 
> * A type name (or Self, which would mimic C++-style private, or perhaps even 
> C++-style protected depending on how we treat inheritance)
> * A module name (or #module for the current module)
> * A file name string (or #file for the current file)
> 
> And then the default would simply be `private(#module)`.
> 
> Alternatively, the parameterized level could be given a different name, like 
> `internal` or `shared`. If that were the case, then `#module` might simply be 
> the default.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

I understand the desire to wrap this up as it has gone on for a long time.

I just don’t like the length and readability of the moduleprivate and 
fileprivate names (and how auto correct is always “fixing” it for me when I try 
to write about it). As I mentioned these will likely be used very often in code 
and just don’t look very nice. These are potentially used on almost every 
method, class, property and struct. I don’t think that we should use something 
that is perhaps a little clearer in meaning but hard to read for something that 
is used so frequently through the code. There are plenty of places where you 
have to look something up the first time you encounter it in any programming 
language and this explicitness is not a big enough win to sacrifice 
readability. A single word keyword is a requirement for me. 


 
> On Mar 30, 2016, at 6:13 AM, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> I am not sure if we will ever get another access level. If we do, great, but 
> given how long this discussion has been already, I am not counting on it :-)
> 
> Most likely, if we get more, it will be possible to describe it with a simple 
> word, or a combination of words or with some common abbreviations, so I am 
> not worried about extensibility. I think that the names in the proposal are 
> very consistent with Swift as it is today and will serve us well. They are 
> also completely unambiguous and don't depend on the reading context, so if we 
> come up with other ways to label access levels, it should still be possible 
> to either use these names for backward compatibility or migrate them 
> automatically to new names without any difference in semantics.
> 
> We also needed to pick something. I waited for about a week to get 
> everybody's vote, and I think that I picked a compromise that we can all be 
> at least ok with. (I also originally wanted short single word names). I think 
> we should close the naming thread at this point.
> On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge  > wrote:
> 
> 
> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution 
> > wrote:
> 
> >> If Scala style access modifiers were adopted for Swift then a 
> >> private(file) modifier would also be necessary to give the current private 
> >> functionality.
> >
> > I could imagine having these options:
> >
> >public// visible to all everyone
> >private(scope-name, scope-name, …)// visible to specified scopes 
> > (plus current scope)
> >private// visible only to current scope
> >
> 
> Allowing multiple "scope-name"s is a lot of flexibility and power, but not 
> sure it's useful/worthwhile.
> 
>  For the current discussion, I would think "scope-name" should be limited to 
> an enclosing scope only.  So you can say "private(Outer)" from an Inner class 
> or "private(#file)" from within a class, but not "private(ClassA)" from 
> within ClassB.
> 
> (This would also solve the ambiguity of how to reference the main ClassA or a 
> specific extension to ClassA... "private(ClassA)" can only refer to whichever 
> scope of ClassA you are currently in.)
> 
> > scope-name could perhaps be:
> >
> > * A type name (or Self, which would mimic C++-style private, or perhaps 
> > even C++-style protected depending on how we treat inheritance)
> 
> But, this is getting into type-based access which is beyond the scope of 
> SE-0025 right?
> 
> > * A module name (or #module for the current module)
> > * A file name string (or #file for the current file)
> >
> > And then the default would simply be `private(#module)`.
> >
> > Alternatively, the parameterized level could be given a different name, 
> > like `internal` or `shared`. If that were the case, then `#module` might 
> > simply be the default.
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

So, just so I'm understanding correctly what the new system would be
(taking into account Chris Lattner's comments).

A symbol specified as 'public' is visible outside the module.
A symbol with no specifier, or specified as 'moduleprivate', is visible
only within the module, but anywhere within it. This default lets us start
coding first and refine visibility later; 'moduleprivate' replaces
'internal'.
A symbol specified as 'fileprivate' is visible only within the file in
which it is declared.
A symbol specified as 'private' is *as private as possible* given its type.

So, if a constant, variable, property, func, enum, struct, etc. is defined
inside of a scope, 'private' makes it visible only within that scope. All
private properties of a nested inner type are visible throughout the scope
of the outer type which contains it, and the inner type can see any private
properties in the scope which contains it.

If a constant, variable, protocol, class etc. is defined outside of a
scope, 'private' is synonymous with 'fileprivate'. (I don't know if using
'fileprivate' on a type which cannot be "scope-private" should generate a
warning.)

Extending to the future: if we add any more levels, they must fit within
the hierarchy (i.e. all levels must be expressible as concentric rings in a
Venn Diagram, no overlapping) and there must be an objective specifier
which signifies its visibility.
So if we add a 'submodule' level, then a submodule must comprise a set of
whole files which is a subset of the containing module. A
'submoduleprivate' symbol is visible anywhere in any of the files it
consists of - there would be no way to mark part of a file as being within
the submodule, and part of the file outside of it.


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

> I believe we will need another non-type access level if frameworks are
> ever divided into submodules.
>
> -DW
>
> On Mar 30, 2016, at 7:13 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I am not sure if we will ever get another access level. If we do, great,
> but given how long this discussion has been already, I am not counting on
> it :-)
>
> Most likely, if we get more, it will be possible to describe it with a
> simple word, or a combination of words or with some common abbreviations,
> so I am not worried about extensibility. I think that the names in the
> proposal are very consistent with Swift as it is today and will serve us
> well. They are also completely unambiguous and don't depend on the reading
> context, so if we come up with other ways to label access levels, it should
> still be possible to either use these names for backward compatibility or
> migrate them automatically to new names without any difference in semantics.
>
> We also needed to pick something. I waited for about a week to get
> everybody's vote, and I think that I picked a compromise that we can all be
> at least ok with. (I also originally wanted short single word names). I
> think we should close the naming thread at this point.
> On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge 
> wrote:
>
>>
>>
>> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> >> If Scala style access modifiers were adopted for Swift then a
>> private(file) modifier would also be necessary to give the current private
>> functionality.
>> >
>> > I could imagine having these options:
>> >
>> >public// visible to all everyone
>> >private(scope-name, scope-name, …)// visible to specified scopes
>> (plus current scope)
>> >private// visible only to current scope
>> >
>>
>> Allowing multiple "scope-name"s is a lot of flexibility and power, but
>> not sure it's useful/worthwhile.
>>
>>  For the current discussion, I would think "scope-name" should be limited
>> to an enclosing scope only.  So you can say "private(Outer)" from an Inner
>> class or "private(#file)" from within a class, but not "private(ClassA)"
>> from within ClassB.
>>
>> (This would also solve the ambiguity of how to reference the main ClassA
>> or a specific extension to ClassA... "private(ClassA)" can only refer to
>> whichever scope of ClassA you are currently in.)
>>
>> > scope-name could perhaps be:
>> >
>> > * A type name (or Self, which would mimic C++-style private, or perhaps
>> even C++-style protected depending on how we treat inheritance)
>>
>> But, this is getting into type-based access which is beyond the scope of
>> SE-0025 right?
>>
>> > * A module name (or #module for the current module)
>> > * A file name string (or #file for the current file)
>> >
>> > And then the default would simply be `private(#module)`.
>> >
>> > Alternatively, the parameterized level could be given a different name,
>> like `internal` or `shared`. If that were the case, then `#module` might
>> simply be the 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Waite via swift-evolution]

I believe we will need another non-type access level if frameworks are ever 
divided into submodules.

-DW

> On Mar 30, 2016, at 7:13 AM, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> I am not sure if we will ever get another access level. If we do, great, but 
> given how long this discussion has been already, I am not counting on it :-)
> 
> Most likely, if we get more, it will be possible to describe it with a simple 
> word, or a combination of words or with some common abbreviations, so I am 
> not worried about extensibility. I think that the names in the proposal are 
> very consistent with Swift as it is today and will serve us well. They are 
> also completely unambiguous and don't depend on the reading context, so if we 
> come up with other ways to label access levels, it should still be possible 
> to either use these names for backward compatibility or migrate them 
> automatically to new names without any difference in semantics.
> 
> We also needed to pick something. I waited for about a week to get 
> everybody's vote, and I think that I picked a compromise that we can all be 
> at least ok with. (I also originally wanted short single word names). I think 
> we should close the naming thread at this point.
> On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge  > wrote:
> 
> 
> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution 
> > wrote:
> 
> >> If Scala style access modifiers were adopted for Swift then a 
> >> private(file) modifier would also be necessary to give the current private 
> >> functionality.
> >
> > I could imagine having these options:
> >
> >public// visible to all everyone
> >private(scope-name, scope-name, …)// visible to specified scopes 
> > (plus current scope)
> >private// visible only to current scope
> >
> 
> Allowing multiple "scope-name"s is a lot of flexibility and power, but not 
> sure it's useful/worthwhile.
> 
>  For the current discussion, I would think "scope-name" should be limited to 
> an enclosing scope only.  So you can say "private(Outer)" from an Inner class 
> or "private(#file)" from within a class, but not "private(ClassA)" from 
> within ClassB.
> 
> (This would also solve the ambiguity of how to reference the main ClassA or a 
> specific extension to ClassA... "private(ClassA)" can only refer to whichever 
> scope of ClassA you are currently in.)
> 
> > scope-name could perhaps be:
> >
> > * A type name (or Self, which would mimic C++-style private, or perhaps 
> > even C++-style protected depending on how we treat inheritance)
> 
> But, this is getting into type-based access which is beyond the scope of 
> SE-0025 right?
> 
> > * A module name (or #module for the current module)
> > * A file name string (or #file for the current file)
> >
> > And then the default would simply be `private(#module)`.
> >
> > Alternatively, the parameterized level could be given a different name, 
> > like `internal` or `shared`. If that were the case, then `#module` might 
> > simply be the default.
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution 
 wrote:

>> If Scala style access modifiers were adopted for Swift then a private(file) 
>> modifier would also be necessary to give the current private functionality.
> 
> I could imagine having these options:
> 
>public// visible to all everyone
>private(scope-name, scope-name, …)// visible to specified scopes (plus 
> current scope)
>private// visible only to current scope
> 

Allowing multiple "scope-name"s is a lot of flexibility and power, but not sure 
it's useful/worthwhile.

 For the current discussion, I would think "scope-name" should be limited to an 
enclosing scope only.  So you can say "private(Outer)" from an Inner class or 
"private(#file)" from within a class, but not "private(ClassA)" from within 
ClassB. 

(This would also solve the ambiguity of how to reference the main ClassA or a 
specific extension to ClassA... "private(ClassA)" can only refer to whichever 
scope of ClassA you are currently in.)

> scope-name could perhaps be:
> 
> * A type name (or Self, which would mimic C++-style private, or perhaps even 
> C++-style protected depending on how we treat inheritance)

But, this is getting into type-based access which is beyond the scope of 
SE-0025 right?

> * A module name (or #module for the current module)
> * A file name string (or #file for the current file)
> 
> And then the default would simply be `private(#module)`.
> 
> Alternatively, the parameterized level could be given a different name, like 
> `internal` or `shared`. If that were the case, then `#module` might simply be 
> the default.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

>> On Mar 29, 2016, at 13:54, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> On Mar 25, 2016, at 10:37 AM, Kevin Lundberg via swift-evolution 
>>  wrote:
>> I use the file-private scope a fair amount for top-level constants that are 
>> intended to be used within the file, possibly across types. Doing things 
>> this way is more concise than embedding them as static members in the type 
>> itself since I don't need to qualify them with the name of the type at the 
>> front.
> 
> This is a great point, and perhaps should be made more clear.  In the 
> degenerate case of a top level declaration, “private” and “fileprivate” are 
> the same thing, since the scope that “private” refers to is the whole file.
> 
>   private let c = 42   // usable within the current file.
> 
>   private struct X { init(a : Int) {…} }  // usable within the current file.
> 
>   func foo() { 
>   let thing = X(a: c)
>   }
> 
> -Chris

This seems to be a strong argument for "private(file)" or "private(#file)" 

There are really just two access levels:
- public // visible everywhere
- private // only visible to current scope

The parenthetical is a way to refer to some enclosing scope broader than the 
current scope.

- Matt

> 
>> 
>> Kevin Lundberg
>> ke...@klundberg.com
>> 
>> 
>> 
>>> On Mar 25, 2016, at 1:11 PM, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution 
  wrote:
 
 
> These are special cases — both file-private and module-private is 
> something that is fairly unusual
 
 afaics this is the third time someone mentions that "file-private" is 
 uncommon — so I think it's time someone dissents:
 That statement is at least subjective… right now, "file-private" is one of 
 three access levels, and I wouldn't dare to say either is more or less 
 important than the others.
 
 I never encountered situations with the current model where I missed a new 
 "private"-level, and maybe "private" will become fairly unusual for the 
 code I'll be writing.
 
 In my existing code, the new meaning of private wouldn't break much, but 
 the current meaning doesn't hurt me, and there are cases where 
 "file-private" is needed.
 
 None the less, I don't care much about the "ugliness" of "fileprivate" — 
 but not because I perceive it as unusual:
 I just expect that code completion will do the typing for me, so maybe "f" 
 will be all I have to write (half the characters of "pr" ;-)
>>> 
>>> I cannot come up with a single use-case in my code for fileprivate and 
>>> would love
>>> some real world examples where you'd want visibility in a single file but 
>>> not across
>>> an entire module.
>>> 
>>> The fileprivate behavior has been a bugaboo of mine for some time, 
>>> particularly in 
>>> playground use. 
>>> 
>>> As far as I'm concerned, the control I really want is public,  
>>> intra-modular, private, and 
>>> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
>>> 
>>> -- E
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Howard Lovatt via swift-evolution]

Yes, #module would be a nice addition and I like the #file and #modules
scope names since they can't clash with user defined names.

  -- Howard.

On 30 March 2016 at 11:47, Brent Royal-Gordon 
wrote:

> > If Scala style access modifiers were adopted for Swift then a
> private(file) modifier would also be necessary to give the current private
> functionality.
>
> I could imagine having these options:
>
> public  // visible
> to all everyone
> private(scope-name, scope-name, …)  // visible to specified
> scopes (plus current scope)
> private // visible
> only to current scope
>
> scope-name could perhaps be:
>
> * A type name (or Self, which would mimic C++-style private, or perhaps
> even C++-style protected depending on how we treat inheritance)
> * A module name (or #module for the current module)
> * A file name string (or #file for the current file)
>
> And then the default would simply be `private(#module)`.
>
> Alternatively, the parameterized level could be given a different name,
> like `internal` or `shared`. If that were the case, then `#module` might
> simply be the default.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Brent Royal-Gordon via swift-evolution]

> If Scala style access modifiers were adopted for Swift then a private(file) 
> modifier would also be necessary to give the current private functionality.

I could imagine having these options:

public  // visible to 
all everyone
private(scope-name, scope-name, …)  // visible to specified scopes 
(plus current scope)
private // visible only 
to current scope

scope-name could perhaps be:

* A type name (or Self, which would mimic C++-style private, or perhaps even 
C++-style protected depending on how we treat inheritance)
* A module name (or #module for the current module)
* A file name string (or #file for the current file)

And then the default would simply be `private(#module)`.

Alternatively, the parameterized level could be given a different name, like 
`internal` or `shared`. If that were the case, then `#module` might simply be 
the default.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Howard Lovatt via swift-evolution]

Scala has a sophisticated and interesting access level that might well be
good fit to Swift (since the two languages are very similar), e.g
Swiftizing some Scala:

class society {

class professional {

class Executive {

private(society) var friends = ...

private(professional) var workDetails = ...

private var secrets = ...


func executive() {

print(friends) // OK inside society

print(workDetails) // OK inside professional

print(secrets) // OK inside Executive

}

}

func professional() {

   print(friends) // OK inside society

   print(workDetails) // OK inside professional

   print(secrets) // ERROR outside Executive

}

}

func society() {

   print(friends) // OK inside society

   print(workDetails) // ERROR outside professional

   print(secrets) // ERROR outside Executive

}

}

var exec = society.professional.Executive()


print(exec.friends) // ERROR outside society
print(exec.workDetails) // ERROR outside professional
print(exec.secrets) // ERROR outside Executive


In Scala access is:

   1. public, private, or private(S); plus protected for abstract classes
   and private(self) for generic classes with generic variance - neither
   relevant to this discussion
   2. public behaves as expected
   3. The default is public, therefore in the example above society,
   professional, Executive, and the functions are all public
   4. private is scoped so that is only visible within its enclosing scope,
   hence secrets is only visible inside Executive
   5. private(S) extends the visibility to the named enclosing scope S,
   hence workDetails is visible inside professional's scope because it is
   declared private(professional)

If Scala style access modifiers were adopted for Swift then a private(file)
modifier would also be necessary to give the current private functionality.

Note Scala has modules, called packages, and in the Scala example I copied
and converted to Swift above the society and professional classes were
packages and hence there lower-case spelling. Class was the nearest
substitute in Swift for a scala package. The original Scala is from:
http://www.tutorialspoint.com/scala/scala_access_modifiers.htm

  -- Howard.

On 29 March 2016 at 07:30, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 28, 2016, at 11:40, Ilya Belenkiy  wrote:
>
> > I *still* don't understand your reasoning here. If a private member can
> be used in a member function, and in closures inside that member function,
> why can't it be used in a member type?
>
> The simplest answer is that it's the most private access level, and also
> one that doesn't create any confusion. We already discussed several times
> here whether inner should have access to outer or the other way around.
> With this design, the answer is neither.
>
> A longer answer is that if you move a function into a type and make it a
> member function, you change the semantics. It's no longer the same
> function. If you move the type inside another type, the semantics is the
> same. The only difference is that we get shorter names. Also, if you move a
> function to be a member function, that changes the class API. If you move a
> class to become a nested class, that does not change the outer class API.
> Both classes can be used the same way but with different spelling of the
> name of the inner class.
>
> Also, I think that the terminology of access level really comes from OOP.
> The problem with the current state of things is that it mixes this
> terminology with export levels. This proposal makes "private" mean what it
> means in OOP and extends it so that it makes sense with Swift extensions.
>
> If we were talking about "scoped" level access, the immediate scope
> addition would be wrong. But if we are talking about "private", it's a
> different matter.
>
>
> I don't buy this argument. Before Swift, there have been plenty of OO
> languages with extensions and plenty with access control, but no major ones
> with both except Ruby (discounting Objective-C's @private instance
> variables). And, ignoring extensions, the behavior of 'private' in all of
> these languages is to include access from member types:
>
> - C++: yes
> - Java: yes
> - C#: yes
>
> - Ruby: no, but even the outer class can't invoke private methods on a
> different instance of itself
> - D: yes, but D's "private" is closer to Swift's current "private" than
> anything else
>
> - Kotlin: yes
> - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access
> control or no nested types, AFAICT
>
> So "private" in these languages doesn't seem to mean "restricted to this
> type", and that shouldn't be considered the "obvious" meaning when several
> of us have considered it decidedly non-obvious.
>
> Best,
> Jordan
>
> P.S. "If you move the type inside another type, the semantics is the
> same." This already isn't true if the new member type is used to satisfy a
> protocol 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Lukas Stabe via swift-evolution]

I'm kind of late to this thread, so if my argument has been brought up before, 
please just ignore me:

I know naming the modifiers `module` and `file` have been suggested already, 
and those were dismissed as being to broadly named. Would these modifiers stand 
on their own, I'd agree with this in full. However, access modifiers always 
accompany something like `let`, `class`, `func` etc.

To give some examples:

module class Worker { ... }

This, to me, sounds exactly like what it would be: A class belonging to the 
module.

file let apiURL = "https://api.example.com/;

Again, imho this describes what it is perfectly: A constant belonging to the 
current file.

Extending this to the new private and to public, I think `public` fits 
reasonably well, and for the new private, something along the lines of `scope` 
could work well:

scope func myUtilityFunction() { ... }

– Lukas

> On 29 Mar 2016, at 13:09, Paul Ossenbruggen via swift-evolution 
>  wrote:
> 
> If someone sees public and external in different places while learning the 
> language they would be curious to see what the difference is. The first time 
> I saw internal in swift, I looked it up. It was not immediately apparent from 
> the name what it meant from then on, there was no confusion. This similarly 
> would apply to external. 
> 
> Since the C extern is a different word, I would not assume it is the same, 
> but may be not that confusing, as it is used in a similar manner to C. You 
> are exposing the item beyond this file. 
> 
> Since external is the default, it would not be seen as often. 
> 
> These specifiers should be single words because they are typed quite often. I 
> think public is the single most word I typed on a library I created. Since 
> they will be seen a lot they should be pleasing to the eye. 
> 
> I would be ok with "shared" for external  but I like the symmetry of 
> internal-external and public-private. Does it then become shared-excluded? 
> Shared-unshared? Still like external-internal better. 
> 
> - Paul 
> 
> Sent from my iPhone
> 
>> On Mar 29, 2016, at 9:31 AM, Jordan Rose  wrote:
>> 
>> I agree with Ilya that "external" is too easy to confuse with "public", 
>> especially given the specifier "extern" in C. Additionally, we think we can 
>> get away with renaming "private" because most current uses of "private" 
>> (file-scoped) declarations are within the same (brace-bound) scope anyway; 
>> "internal" could potentially cause a lot more churn. And as Andrey pointed 
>> out, we'd be at odds with C#, the only other language that uses "internal" 
>> as an access specifier today.
>> 
>> Jordan
>> 
>> 
>>> On Mar 29, 2016, at 7:03 , Ilya Belenkiy via swift-evolution 
>>>  wrote:
>>> 
>>> -1, "external" can be also understood as "exported" or public. I think that 
>>> the names in the updated proposal are the clearest. Also, I think that at 
>>> this point we need to stop trying to come up with more names. I don't think 
>>> that we will ever reach a point where everybody is happy with the names. 
>>> The ones that we have now seems to be a good compromise that is in line 
>>> with other Swift keywords.
>>> On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen via swift-evolution 
>>>  wrote:
 
>> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution 
>>  wrote:
>> 
>> public (unchanged)
>> external (module access)
>> internal (file access)
>> private (scoped access)
> 
> 
> This seems logical and something I could live with, but how is it better 
> than moduleprivate and fileprivate? Also, internal has contradictory 
> prior art in C# and Swift 2 (not that it stops us).
> 
> And I see the length of moduleprivate and fileprivate as a feature, and 
> external/internal lacks it.
 
 
 It is better than moduleprivate and fileprivate in that it is a single 
 word which is easier to to read and there is less typing. Less typing even 
 with autocomplete is a benefit. Once you know its meaning, that both are 
 relative to file access, you won’t have to look it up. Also, just noticed 
 this, when I type multiword keywords in an email program or chat program 
 autocorrect butts in. This is of practical value because much work is done 
 in chat and email programs. 
 
 Simpler is better if it sufficiently conveys the meaning and it does in 
 this case. The expectation with most keywords are that they be single 
 words, especially ones that are used the most. 
 
 There is a nice symmetry to internal/external and public/private.
 
 If external/internal refer to the file, then we don’t need the multiword 
 descriptive versions.  Also, if we decide later that scoping to namespaces 
 is desired these same already reserved keywords give us more 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

If someone sees public and external in different places while learning the 
language they would be curious to see what the difference is. The first time I 
saw internal in swift, I looked it up. It was not immediately apparent from the 
name what it meant from then on, there was no confusion. This similarly would 
apply to external. 

Since the C extern is a different word, I would not assume it is the same, but 
may be not that confusing, as it is used in a similar manner to C. You are 
exposing the item beyond this file. 

Since external is the default, it would not be seen as often. 

These specifiers should be single words because they are typed quite often. I 
think public is the single most word I typed on a library I created. Since they 
will be seen a lot they should be pleasing to the eye. 

I would be ok with "shared" for external  but I like the symmetry of 
internal-external and public-private. Does it then become shared-excluded? 
Shared-unshared? Still like external-internal better. 

- Paul 

Sent from my iPhone

> On Mar 29, 2016, at 9:31 AM, Jordan Rose  wrote:
> 
> I agree with Ilya that "external" is too easy to confuse with "public", 
> especially given the specifier "extern" in C. Additionally, we think we can 
> get away with renaming "private" because most current uses of "private" 
> (file-scoped) declarations are within the same (brace-bound) scope anyway; 
> "internal" could potentially cause a lot more churn. And as Andrey pointed 
> out, we'd be at odds with C#, the only other language that uses "internal" as 
> an access specifier today.
> 
> Jordan
> 
> 
>> On Mar 29, 2016, at 7:03 , Ilya Belenkiy via swift-evolution 
>>  wrote:
>> 
>> -1, "external" can be also understood as "exported" or public. I think that 
>> the names in the updated proposal are the clearest. Also, I think that at 
>> this point we need to stop trying to come up with more names. I don't think 
>> that we will ever reach a point where everybody is happy with the names. The 
>> ones that we have now seems to be a good compromise that is in line with 
>> other Swift keywords.
>> On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen via swift-evolution 
>>  wrote:
>>> 
> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution 
>  wrote:
> 
> public (unchanged)
> external (module access)
> internal (file access)
> private (scoped access)
 
 
 This seems logical and something I could live with, but how is it better 
 than moduleprivate and fileprivate? Also, internal has contradictory prior 
 art in C# and Swift 2 (not that it stops us).
 
 And I see the length of moduleprivate and fileprivate as a feature, and 
 external/internal lacks it.
>>> 
>>> 
>>> It is better than moduleprivate and fileprivate in that it is a single word 
>>> which is easier to to read and there is less typing. Less typing even with 
>>> autocomplete is a benefit. Once you know its meaning, that both are 
>>> relative to file access, you won’t have to look it up. Also, just noticed 
>>> this, when I type multiword keywords in an email program or chat program 
>>> autocorrect butts in. This is of practical value because much work is done 
>>> in chat and email programs. 
>>> 
>>> Simpler is better if it sufficiently conveys the meaning and it does in 
>>> this case. The expectation with most keywords are that they be single 
>>> words, especially ones that are used the most. 
>>> 
>>> There is a nice symmetry to internal/external and public/private.
>>> 
>>> If external/internal refer to the file, then we don’t need the multiword 
>>> descriptive versions.  Also, if we decide later that scoping to namespaces 
>>> is desired these same already reserved keywords give us more flexibility 
>>> than the more specific keywords would allow. Internal/external could refer 
>>> to the namespace scope rather than the file scope if it is inside a 
>>> namespace (this is beyond the scope of the proposal but trying to think 
>>> ahead). By not explicitly stating the scope you gain flexibility 
>>> 
>>> - Paul
>>> 
>>> ___
>>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Chris Lattner via swift-evolution]

> On Mar 28, 2016, at 6:38 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>>> On Mar 28, 2016, at 18:20, Matthew Judge  wrote:
>>> 
>>> There are two different  questions that we keep bouncing back and forth 
>>> between. Given:
>>> 
>>> class Outer {
>>>   private var outerVar: Int
>>>   class Inner {
>>>   private var innerVar: Int
>>>   }
>>> }
>>> 
>>> Is outerVar visible inside Inner? To me this seems 'obvious'... Yes.
>>> 
>>> Is innerVar visible to Outer? The answer to this impacts what I think the 
>>> access modifiers should be called.
>> 
>> Fair question. Data:
>> 
>> - C++: no, but the language has "friend".
>> - Java: yes
>> - C#: no
>> 
>> - Ruby: no, but "private" means something slightly different
>> - D: yes, but "private" means something more like Swift's current "private"
>> 
>> - Kotlin: no
>> - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access control 
>> or no nested types, AFAICT
>> 
>> So it's tending towards "no" but it's not as consistent. I agree that if we 
>> pick "yes" then (for example) "scoped" would be a confusing name.
> 
> No is the only answer that is consistent with Swift’s other access modifiers 
> - i.e. strictly based on lexical scope.  My opinion is that we should stick 
> to strict lexical scoping.  It is a simple and consistent principle that is 
> easy to understand and explain.

+1

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Owens II via swift-evolution]

> On Mar 29, 2016, at 10:18 AM, Jordan Rose  wrote:
> 
> A good handful of people already enumerated several cases where file-based 
> scoping is useful, and I very much agree. Leaking helper operations across an 
> entire module just because they can't be lexically scoped, or don't make 
> sense to, doesn't seem like a good answer to me.

I know, I'm one of them.

However, this thread is fairly disconcerting about how granular many of the 
suggestions are heading towards. We can try to solve for all of the cases or we 
can provide mechanism that works well for the majority of cases. I'm actually 
in the camp of keeping the levels as they are. There is always going to be some 
level of leakage unless you provide a mechanism to provide very explicit access 
control modifiers.

The question at the heart of this proposal is how "correct" is Swift really 
going to be in defining access control modifiers?

One can argue that file-based access control is required, for many use cases, 
because it's not possible to limit usage to be "more correct". If I want to 
expose the private details of my type to an extension, how do I do that? Today, 
file-based, but tomorrow, is there a `protected` for this? What about only to 
all extensions within the module? Is that `protected internal`? Is there a way 
to limit the extensions that can have access to the privates, because there are 
real scenarios for that as well?

Then we need to go down the rabbit-hole for type-based access control modifiers 
as well, though maybe that's already alluded to with the extensions example, so 
we get `protected` and `protected internal` there as well.

So this gives us public, internal, private, file-based, protected 
(protocol/extension based), protected (inheritance based), protected internal 
(protocol/extension based), and protected internal (inheritance based). 

And let's not forget the desire to share privates with others that are not in 
our access control scope, so we're back to needing something like `friend` to 
essentially merge other types into the same access control scope.

I really feel like I'm watching the evolution of C++ access modifiers in Swift. 
If that's the route the language and community wants to go, then ok. However, 
if Swift is really going to re-look at access levels, just looking at scoped 
access levels does not seem sufficient; it solves one, very narrow case, while 
ignoring many of the other cases. 

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Chris Lattner via swift-evolution]

On Mar 25, 2016, at 10:37 AM, Kevin Lundberg via swift-evolution 
 wrote:
> I use the file-private scope a fair amount for top-level constants that are 
> intended to be used within the file, possibly across types. Doing things this 
> way is more concise than embedding them as static members in the type itself 
> since I don't need to qualify them with the name of the type at the front.

This is a great point, and perhaps should be made more clear.  In the 
degenerate case of a top level declaration, “private” and “fileprivate” are the 
same thing, since the scope that “private” refers to is the whole file.

private let c = 42   // usable within the current file.

private struct X { init(a : Int) {…} }  // usable within the current 
file.

func foo() { 
let thing = X(a: c)
}

-Chris



> 
> Kevin Lundberg
> ke...@klundberg.com
> 
> 
> 
>> On Mar 25, 2016, at 1:11 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution 
>>>  wrote:
>>> 
>>> 
 These are special cases — both file-private and module-private is 
 something that is fairly unusual
>>> 
>>> afaics this is the third time someone mentions that "file-private" is 
>>> uncommon — so I think it's time someone dissents:
>>> That statement is at least subjective… right now, "file-private" is one of 
>>> three access levels, and I wouldn't dare to say either is more or less 
>>> important than the others.
>>> 
>>> I never encountered situations with the current model where I missed a new 
>>> "private"-level, and maybe "private" will become fairly unusual for the 
>>> code I'll be writing.
>>> 
>>> In my existing code, the new meaning of private wouldn't break much, but 
>>> the current meaning doesn't hurt me, and there are cases where 
>>> "file-private" is needed.
>>> 
>>> None the less, I don't care much about the "ugliness" of "fileprivate" — 
>>> but not because I perceive it as unusual:
>>> I just expect that code completion will do the typing for me, so maybe "f" 
>>> will be all I have to write (half the characters of "pr" ;-)
>> 
>> I cannot come up with a single use-case in my code for fileprivate and would 
>> love
>> some real world examples where you'd want visibility in a single file but 
>> not across
>> an entire module.
>> 
>> The fileprivate behavior has been a bugaboo of mine for some time, 
>> particularly in 
>> playground use. 
>> 
>> As far as I'm concerned, the control I really want is public,  
>> intra-modular, private, and 
>> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
>> 
>> -- E
>> 
>> 
>> 
>> 
>> ___
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 29, 2016, at 12:18 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>>> On Mar 29, 2016, at 10:14 , David Owens II  wrote:
>>> 
>>> Additionally, we think we can get away with renaming "private" because most 
>>> current uses of "private" (file-scoped) declarations are within the same 
>>> (brace-bound) scope anyway;
>> 
>> A quick look through my code bases verifies that this is true with my small 
>> sample of code. The only outliers are private members on types accessed by 
>> extensions, but those are fairly rare in my use cases, and arguably, those 
>> should be changed to internal. Maybe that varies for others.
>> 
>> Honestly, if the assertion is already that most of the current private use 
>> cases are for lexically scoped uses anyway, is it really worth trying to add 
>> a file-based private as well that essentially pops out of the lexical scope 
>> only up to the file level? For those use cases, just use `internal`. Using 
>> `private` would still be available for top-level declarations on the file.
>> 
>> We would end up with just this:
>> 
>> `public` - publicly exported for use by all code that uses the library
>> `internal` - only allowed for use within the current module
>> `private` - the new, lexically scoped modifier
>> 
>> If file-based is really required for a small set of cases, use `private 
>> internal`.
> 
> A good handful of people already enumerated several cases where file-based 
> scoping is useful, and I very much agree. Leaking helper operations across an 
> entire module just because they can't be lexically scoped, or don't make 
> sense to, doesn't seem like a good answer to me.

+1

> 
> Jordan
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

> On Mar 29, 2016, at 10:14 , David Owens II  wrote:
> 
>> Additionally, we think we can get away with renaming "private" because most 
>> current uses of "private" (file-scoped) declarations are within the same 
>> (brace-bound) scope anyway;
> 
> A quick look through my code bases verifies that this is true with my small 
> sample of code. The only outliers are private members on types accessed by 
> extensions, but those are fairly rare in my use cases, and arguably, those 
> should be changed to internal. Maybe that varies for others.
> 
> Honestly, if the assertion is already that most of the current private use 
> cases are for lexically scoped uses anyway, is it really worth trying to add 
> a file-based private as well that essentially pops out of the lexical scope 
> only up to the file level? For those use cases, just use `internal`. Using 
> `private` would still be available for top-level declarations on the file.
> 
> We would end up with just this:
> 
> `public` - publicly exported for use by all code that uses the library
> `internal` - only allowed for use within the current module
> `private` - the new, lexically scoped modifier
> 
> If file-based is really required for a small set of cases, use `private 
> internal`.

A good handful of people already enumerated several cases where file-based 
scoping is useful, and I very much agree. Leaking helper operations across an 
entire module just because they can't be lexically scoped, or don't make sense 
to, doesn't seem like a good answer to me.

Jordan

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[David Owens II via swift-evolution]

> Additionally, we think we can get away with renaming "private" because most 
> current uses of "private" (file-scoped) declarations are within the same 
> (brace-bound) scope anyway;

A quick look through my code bases verifies that this is true with my small 
sample of code. The only outliers are private members on types accessed by 
extensions, but those are fairly rare in my use cases, and arguably, those 
should be changed to internal. Maybe that varies for others.

Honestly, if the assertion is already that most of the current private use 
cases are for lexically scoped uses anyway, is it really worth trying to add a 
file-based private as well that essentially pops out of the lexical scope only 
up to the file level? For those use cases, just use `internal`. Using `private` 
would still be available for top-level declarations on the file.

We would end up with just this:

`public` - publicly exported for use by all code that uses the library
`internal` - only allowed for use within the current module
`private` - the new, lexically scoped modifier

If file-based is really required for a small set of cases, use `private 
internal`.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

I checked this out when I was making my lists. It's a very simple solution, but 
I feel like "internal (module-scoped) method on a public class" is a common 
enough use case that we wouldn't want to rule it out, or force the user to 
write a separate extension.

Jordan


> On Mar 29, 2016, at 8:12 , Thorsten Seitz via swift-evolution 
>  wrote:
> 
> FWIW, Ceylon uses only a lexical access level like in the proposal (as I 
> understood it):
> 
> program elements which are visible only inside the scope in which they are 
> defined, and
> program elements which are visible wherever the thing they belong to (a type, 
> package, or module) is visible.
> 
> In Ceylon this level is called "shared".
> 
> -Thorsten 
> 
> Am 29.03.2016 um 16:24 schrieb Paul Ossenbruggen via swift-evolution 
> >:
> 
>> Just as context is used for variable names does not need a specific scoping 
>> specifier every time one is declared.  You know from the context in which it 
>> is used that it only applies to a certain scope. 
>> 
>> I would hope that if namespaces are added we would not have namespaceprivate 
>> etc The keywords would explode and become quite confusing..Instead if it is 
>> in a namespace you would use internal or external and the scope changes to 
>> the namespace rather than the file but as I said this is beyond the intent 
>> of this proposal. 
>> 
>>> On Mar 29, 2016, at 7:04 AM, Ross O'Brien >> > wrote:
>>> 
>>> How is flexibility desirable?
>>> 
>>> Why is it important to me, if I decide that a given class should only be 
>>> visible at 'internal' scope, that the meaning of 'internal' should be 
>>> subject to change in future versions of Swift? 'Once you know its meaning' 
>>> should mean once!
>>> 
>>> Right now, I use the word 'private' when I want code to be only visible 
>>> within a file. When I migrate a project to Swift 3, an automatic migrator 
>>> may not be able to tell whether a given private property should now be 
>>> scope-private or file-private. Perhaps we can assume that anything private 
>>> referred to in more than one scope should be file-private and everything 
>>> remaining should be scope-private, but I think it would still be wise to 
>>> manually review the changes. Using 'internal' to replace 'private' may make 
>>> that process even more complicated... but okay, it's a one-time cost.
>>> 
>>> I don't see the advantage in knowing that adding another visibility level 
>>> in future will require another intensive review. I'd prefer it if a keyword 
>>> was explicit about its meaning. Migration can then be straightforward: 
>>> everything 'private' now can become 'file-private', and if I want to reduce 
>>> the visibility of anything to scope-private then I can do so manually. If 
>>> we add an even more private level in future then the code doesn't break 
>>> just because 'private' was too subjective in its meaning.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Mar 29, 2016 at 2:23 PM, Paul Ossenbruggen via swift-evolution 
>>> > wrote:
>>> 
 On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution 
 > wrote:
 
> public (unchanged)
> external (module access)
> internal (file access)
> private (scoped access)
 
 
 This seems logical and something I could live with, but how is it better 
 than moduleprivate and fileprivate? Also, internal has contradictory prior 
 art in C# and Swift 2 (not that it stops us).
 
 And I see the length of moduleprivate and fileprivate as a feature, and 
 external/internal lacks it.
>>> 
>>> 
>>> It is better than moduleprivate and fileprivate in that it is a single word 
>>> which is easier to to read and there is less typing. Less typing even with 
>>> autocomplete is a benefit. Once you know its meaning, that both are 
>>> relative to file access, you won’t have to look it up. Also, just noticed 
>>> this, when I type multiword keywords in an email program or chat program 
>>> autocorrect butts in. This is of practical value because much work is done 
>>> in chat and email programs. 
>>> 
>>> Simpler is better if it sufficiently conveys the meaning and it does in 
>>> this case. The expectation with most keywords are that they be single 
>>> words, especially ones that are used the most. 
>>> 
>>> There is a nice symmetry to internal/external and public/private.
>>> 
>>> If external/internal refer to the file, then we don’t need the multiword 
>>> descriptive versions.  Also, if we decide later that scoping to namespaces 
>>> is desired these same already reserved keywords give us more flexibility 
>>> than the more specific keywords would allow. Internal/external could refer 
>>> to the namespace scope rather than the file 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Thorsten Seitz via swift-evolution]

FWIW, Ceylon uses only a lexical access level like in the proposal (as I 
understood it):

program elements which are visible only inside the scope in which they are 
defined, and
program elements which are visible wherever the thing they belong to (a type, 
package, or module) is visible.

In Ceylon this level is called "shared".

-Thorsten 

> Am 29.03.2016 um 16:24 schrieb Paul Ossenbruggen via swift-evolution 
> :
> 
> Just as context is used for variable names does not need a specific scoping 
> specifier every time one is declared.  You know from the context in which it 
> is used that it only applies to a certain scope. 
> 
> I would hope that if namespaces are added we would not have namespaceprivate 
> etc The keywords would explode and become quite confusing..Instead if it is 
> in a namespace you would use internal or external and the scope changes to 
> the namespace rather than the file but as I said this is beyond the intent of 
> this proposal. 
> 
>> On Mar 29, 2016, at 7:04 AM, Ross O'Brien  
>> wrote:
>> 
>> How is flexibility desirable?
>> 
>> Why is it important to me, if I decide that a given class should only be 
>> visible at 'internal' scope, that the meaning of 'internal' should be 
>> subject to change in future versions of Swift? 'Once you know its meaning' 
>> should mean once!
>> 
>> Right now, I use the word 'private' when I want code to be only visible 
>> within a file. When I migrate a project to Swift 3, an automatic migrator 
>> may not be able to tell whether a given private property should now be 
>> scope-private or file-private. Perhaps we can assume that anything private 
>> referred to in more than one scope should be file-private and everything 
>> remaining should be scope-private, but I think it would still be wise to 
>> manually review the changes. Using 'internal' to replace 'private' may make 
>> that process even more complicated... but okay, it's a one-time cost.
>> 
>> I don't see the advantage in knowing that adding another visibility level in 
>> future will require another intensive review. I'd prefer it if a keyword was 
>> explicit about its meaning. Migration can then be straightforward: 
>> everything 'private' now can become 'file-private', and if I want to reduce 
>> the visibility of anything to scope-private then I can do so manually. If we 
>> add an even more private level in future then the code doesn't break just 
>> because 'private' was too subjective in its meaning.
>> 
>> 
>> 
>> 
>> 
>>> On Tue, Mar 29, 2016 at 2:23 PM, Paul Ossenbruggen via swift-evolution 
>>>  wrote:
>>> 
> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution 
>  wrote:
> 
> public (unchanged)
> external (module access)
> internal (file access)
> private (scoped access)
 
 
 This seems logical and something I could live with, but how is it better 
 than moduleprivate and fileprivate? Also, internal has contradictory prior 
 art in C# and Swift 2 (not that it stops us).
 
 And I see the length of moduleprivate and fileprivate as a feature, and 
 external/internal lacks it.
>>> 
>>> 
>>> It is better than moduleprivate and fileprivate in that it is a single word 
>>> which is easier to to read and there is less typing. Less typing even with 
>>> autocomplete is a benefit. Once you know its meaning, that both are 
>>> relative to file access, you won’t have to look it up. Also, just noticed 
>>> this, when I type multiword keywords in an email program or chat program 
>>> autocorrect butts in. This is of practical value because much work is done 
>>> in chat and email programs. 
>>> 
>>> Simpler is better if it sufficiently conveys the meaning and it does in 
>>> this case. The expectation with most keywords are that they be single 
>>> words, especially ones that are used the most. 
>>> 
>>> There is a nice symmetry to internal/external and public/private.
>>> 
>>> If external/internal refer to the file, then we don’t need the multiword 
>>> descriptive versions.  Also, if we decide later that scoping to namespaces 
>>> is desired these same already reserved keywords give us more flexibility 
>>> than the more specific keywords would allow. Internal/external could refer 
>>> to the namespace scope rather than the file scope if it is inside a 
>>> namespace (this is beyond the scope of the proposal but trying to think 
>>> ahead). By not explicitly stating the scope you gain flexibility 
>>> 
>>> - Paul
>>> 
>>> 
>>> ___
>>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

How is flexibility desirable?

Why is it important to me, if I decide that a given class should only be
visible at 'internal' scope, that the meaning of 'internal' should be
subject to change in future versions of Swift? 'Once you know its meaning'
should mean once!

Right now, I use the word 'private' when I want code to be only visible
within a file. When I migrate a project to Swift 3, an automatic migrator
may not be able to tell whether a given private property should now be
scope-private or file-private. Perhaps we can assume that anything private
referred to in more than one scope should be file-private and everything
remaining should be scope-private, but I think it would still be wise to
manually review the changes. Using 'internal' to replace 'private' may make
that process even more complicated... but okay, it's a one-time cost.

I don't see the advantage in knowing that adding another visibility level
in future will require another intensive review. I'd prefer it if a keyword
was explicit about its meaning. Migration can then be straightforward:
everything 'private' now can become 'file-private', and if I want to reduce
the visibility of anything to scope-private then I can do so manually. If
we add an even more private level in future then the code doesn't break
just because 'private' was too subjective in its meaning.





On Tue, Mar 29, 2016 at 2:23 PM, Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> public (unchanged)
> external (module access)
> internal (file access)
> private (scoped access)
>
>
> This seems logical and something I could live with, but how is it better
> than moduleprivate and fileprivate? Also, internal has contradictory prior
> art in C# and Swift 2 (not that it stops us).
>
> And I see the length of moduleprivate and fileprivate as a feature, and
> external/internal lacks it.
>
>
> It is better than moduleprivate and fileprivate in that it is a single
> word which is easier to to read and there is less typing. Less typing even
> with autocomplete is a benefit. Once you know its meaning, that both are
> relative to file access, you won’t have to look it up. Also, just noticed
> this, when I type multiword keywords in an email program or chat program
> autocorrect butts in. This is of practical value because much work is done
> in chat and email programs.
>
> Simpler is better if it sufficiently conveys the meaning and it does in
> this case. The expectation with most keywords are that they be single
> words, especially ones that are used the most.
>
> There is a nice symmetry to internal/external and public/private.
>
> If external/internal refer to the file, then we don’t need the multiword
> descriptive versions.  Also, if we decide later that scoping to namespaces
> is desired these same already reserved keywords give us more flexibility
> than the more specific keywords would allow. Internal/external could refer
> to the namespace scope rather than the file scope if it is inside a
> namespace (this is beyond the scope of the proposal but trying to think
> ahead). By not explicitly stating the scope you gain flexibility
>
> - Paul
>
>
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

-1, "external" can be also understood as "exported" or public. I think that
the names in the updated proposal are the clearest. Also, I think that at
this point we need to stop trying to come up with more names. I don't think
that we will ever reach a point where everybody is happy with the names.
The ones that we have now seems to be a good compromise that is in line
with other Swift keywords.
On Tue, Mar 29, 2016 at 9:23 AM Paul Ossenbruggen via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> public (unchanged)
> external (module access)
> internal (file access)
> private (scoped access)
>
>
> This seems logical and something I could live with, but how is it better
> than moduleprivate and fileprivate? Also, internal has contradictory prior
> art in C# and Swift 2 (not that it stops us).
>
> And I see the length of moduleprivate and fileprivate as a feature, and
> external/internal lacks it.
>
>
> It is better than moduleprivate and fileprivate in that it is a single
> word which is easier to to read and there is less typing. Less typing even
> with autocomplete is a benefit. Once you know its meaning, that both are
> relative to file access, you won’t have to look it up. Also, just noticed
> this, when I type multiword keywords in an email program or chat program
> autocorrect butts in. This is of practical value because much work is done
> in chat and email programs.
>
> Simpler is better if it sufficiently conveys the meaning and it does in
> this case. The expectation with most keywords are that they be single
> words, especially ones that are used the most.
>
> There is a nice symmetry to internal/external and public/private.
>
> If external/internal refer to the file, then we don’t need the multiword
> descriptive versions.  Also, if we decide later that scoping to namespaces
> is desired these same already reserved keywords give us more flexibility
> than the more specific keywords would allow. Internal/external could refer
> to the namespace scope rather than the file scope if it is inside a
> namespace (this is beyond the scope of the proposal but trying to think
> ahead). By not explicitly stating the scope you gain flexibility
>
> - Paul
>
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Thorsten Seitz via swift-evolution]

> Am 25.03.2016 um 18:36 schrieb Michel Fortin via swift-evolution 
> :
> 
>> Le 25 mars 2016 à 12:57, Tino Heth via swift-evolution 
>>  a écrit :
>> 
>> afaics this is the third time someone mentions that "file-private" is 
>> uncommon — so I think it's time someone dissents:
> 
> I'll do the same. There's many instances in my code where I rely on the 
> file-private behavior of Swift 2's private. Mostly this happens when I have a 
> pair of coupled classes that are meant to be used together and that need to 
> access internal details of each other. Most declarations can be scope-private 
> without problem, but it's not that uncommon for me to take advantage of 
> file-private. 

+1


> 
> There's another aspect that is bothering me about these long names. It seems 
> that everyone agrees that writing internal is a rare thing. Still, if you 
> look at generated headers in Xcode you'll see internal everywhere, like this:
> 
> internal class ItemDataModel {
> internal var storage: ItemStorage { get set }
> internal let fileType: String
> required internal init(fileType: String, storage: ItemStorage = default)
> }
> 
> Since internal is the default, it's quite common in generated headers. 
> "moduleprivate" wouldn't be an improvement for legibility here. But perhaps 
> no one but me looks at generated headers for my own project.

Additionally Jordan noted that there might be a policy to always use explicit 
access control. In our Java projects we certainly do this because the default 
"package" level is quite unusual there and omitting it is easily intepreted as 
being an oversight instead of intentional.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Paul Ossenbruggen via swift-evolution]

I like this, it has been suggested already, single words for easy reading (just 
looks nicer). follows precedent in other languages for existing words, new 
words for new concepts. Internal gets demoted from current swift but since that 
was a swift concept we have more control. 

public - outside module
external - external to file - default - need to look up first time they see it, 
but once learned, won’t forget.
internal - file internal - people need to look it up first time they see it, 
but once learned, won’t forget. 
private - private to class. 


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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

I lean towards no as well, but this implies an infinite level of access 
modifiers:
public
private(module) // current internal
private(file) // current private
private(Outer) // all of the rest are the new private
private(Inner)
private(InnersInner)
etc.

The bike shedding has been focused on renaming the current private (and maybe 
the current internal)  and all of the remaining levels will be called private. 
I don't see private(file) and private(module) as special cases, just the most 
common ones... along with private(Outer).

(Note: private(Outer) and the like aren't meant as proposed syntax and have 
problems, but hopefully the meaning is clear in context.)

> On Mar 28, 2016, at 21:38, Matthew Johnson  wrote:
> 
> 
>> On Mar 28, 2016, at 8:32 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Mar 28, 2016, at 18:20, Matthew Judge  wrote:
>>> 
>>> There are two different  questions that we keep bouncing back and forth 
>>> between. Given:
>>> 
>>> class Outer {
>>>   private var outerVar: Int
>>>   class Inner {
>>>   private var innerVar: Int
>>>   }
>>> }
>>> 
>>> Is outerVar visible inside Inner? To me this seems 'obvious'... Yes.
>>> 
>>> Is innerVar visible to Outer? The answer to this impacts what I think the 
>>> access modifiers should be called.
>> 
>> Fair question. Data:
>> 
>> - C++: no, but the language has "friend".
>> - Java: yes
>> - C#: no
>> 
>> - Ruby: no, but "private" means something slightly different
>> - D: yes, but "private" means something more like Swift's current "private"
>> 
>> - Kotlin: no
>> - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access control 
>> or no nested types, AFAICT
>> 
>> So it's tending towards "no" but it's not as consistent. I agree that if we 
>> pick "yes" then (for example) "scoped" would be a confusing name.
> 
> No is the only answer that is consistent with Swift’s other access modifiers 
> - i.e. strictly based on lexical scope.  My opinion is that we should stick 
> to strict lexical scoping.  It is a simple and consistent principle that is 
> easy to understand and explain.
> 
>> 
>> Jordan
>> 
>> ___
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

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.)
https://github.com/apple/swift-evolution/pull/235
(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:
> https://github.com/apple/swift-evolution/pull/234
>
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Johnson via swift-evolution]

> On Mar 28, 2016, at 8:32 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Mar 28, 2016, at 18:20, Matthew Judge  wrote:
>> 
>> There are two different  questions that we keep bouncing back and forth 
>> between. Given:
>> 
>> class Outer {
>>private var outerVar: Int
>>class Inner {
>>private var innerVar: Int
>>}
>> }
>> 
>> Is outerVar visible inside Inner? To me this seems 'obvious'... Yes.
>> 
>> Is innerVar visible to Outer? The answer to this impacts what I think the 
>> access modifiers should be called.
> 
> Fair question. Data:
> 
> - C++: no, but the language has "friend".
> - Java: yes
> - C#: no
> 
> - Ruby: no, but "private" means something slightly different
> - D: yes, but "private" means something more like Swift's current "private"
> 
> - Kotlin: no
> - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access control 
> or no nested types, AFAICT
> 
> So it's tending towards "no" but it's not as consistent. I agree that if we 
> pick "yes" then (for example) "scoped" would be a confusing name.

No is the only answer that is consistent with Swift’s other access modifiers - 
i.e. strictly based on lexical scope.  My opinion is that we should stick to 
strict lexical scoping.  It is a simple and consistent principle that is easy 
to understand and explain.

> 
> Jordan
> 
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

> On Mar 28, 2016, at 18:20, Matthew Judge  wrote:
> 
> There are two different  questions that we keep bouncing back and forth 
> between. Given:
> 
> class Outer {
> private var outerVar: Int
> class Inner {
> private var innerVar: Int
> }
> }
> 
> Is outerVar visible inside Inner? To me this seems 'obvious'... Yes.
> 
> Is innerVar visible to Outer? The answer to this impacts what I think the 
> access modifiers should be called.

Fair question. Data:

- C++: no, but the language has "friend".
- Java: yes
- C#: no

- Ruby: no, but "private" means something slightly different
- D: yes, but "private" means something more like Swift's current "private"

- Kotlin: no
- Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access control or 
no nested types, AFAICT

So it's tending towards "no" but it's not as consistent. I agree that if we 
pick "yes" then (for example) "scoped" would be a confusing name.

Jordan

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

There are two different  questions that we keep bouncing back and forth 
between. Given:

class Outer {
private var outerVar: Int
class Inner {
private var innerVar: Int
}
}

Is outerVar visible inside Inner? To me this seems 'obvious'... Yes.

Is innerVar visible to Outer? The answer to this impacts what I think the 
access modifiers should be called.

> On Mar 28, 2016, at 18:05, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> Ok, I guess I never used nested types much in C++. If this is standard, I 
> don't want to change it. I'll revert back to the pure "scoped" meaning. Thank 
> you, this was very useful.
> 
> On Mon, Mar 28, 2016 at 4:30 PM Jordan Rose  wrote:
>>> On Mar 28, 2016, at 11:40, Ilya Belenkiy  wrote:
>>> 
>> 
>>> > I still don't understand your reasoning here. If a private member can be 
>>> > used in a member function, and in closures inside that member function, 
>>> > why can't it be used in a member type?
>>> 
>> 
>>> The simplest answer is that it's the most private access level, and also 
>>> one that doesn't create any confusion. We already discussed several times 
>>> here whether inner should have access to outer or the other way around. 
>>> With this design, the answer is neither.
>>> 
>>> A longer answer is that if you move a function into a type and make it a 
>>> member function, you change the semantics. It's no longer the same 
>>> function. If you move the type inside another type, the semantics is the 
>>> same. The only difference is that we get shorter names. Also, if you move a 
>>> function to be a member function, that changes the class API. If you move a 
>>> class to become a nested class, that does not change the outer class API. 
>>> Both classes can be used the same way but with different spelling of the 
>>> name of the inner class.
>>> 
>>> Also, I think that the terminology of access level really comes from OOP. 
>>> The problem with the current state of things is that it mixes this 
>>> terminology with export levels. This proposal makes "private" mean what it 
>>> means in OOP and extends it so that it makes sense with Swift extensions.
>>> 
>>> If we were talking about "scoped" level access, the immediate scope 
>>> addition would be wrong. But if we are talking about "private", it's a 
>>> different matter.
>> 
>> 
>> I don't buy this argument. Before Swift, there have been plenty of OO 
>> languages with extensions and plenty with access control, but no major ones 
>> with both except Ruby (discounting Objective-C's @private instance 
>> variables). And, ignoring extensions, the behavior of 'private' in all of 
>> these languages is to include access from member types:
>> 
>> - C++: yes
>> - Java: yes
>> - C#: yes
>> 
>> - Ruby: no, but even the outer class can't invoke private methods on a 
>> different instance of itself
>> - D: yes, but D's "private" is closer to Swift's current "private" than 
>> anything else
>> 
>> - Kotlin: yes
>> - Scala, Python, Go, Rust, Objective-C, Smalltalk: either no access control 
>> or no nested types, AFAICT
>> 
>> So "private" in these languages doesn't seem to mean "restricted to this 
>> type", and that shouldn't be considered the "obvious" meaning when several 
>> of us have considered it decidedly non-obvious.
>> 
>> Best,
>> Jordan
>> 
>> P.S. "If you move the type inside another type, the semantics is the same." 
>> This already isn't true if the new member type is used to satisfy a protocol 
>> requirement (which, because of retroactive modeling, counts as "changing the 
>> class's API"), but it especially won't be true if/when we start allowing 
>> member types inside generic types. In that case, the inner type now has 
>> extra generic parameterization that it wouldn't have had before.
>> 
>> P.S. Extensions do make things a little more complicated, but again, there's 
>> almost no precedent here, and pretty much everyone agrees that this new 
>> scope-private access level shouldn't give access to extensions. That also 
>> means there's an option to keep yourself from accidentally accessing 
>> scope-private members in a member type: put the member type in an extension.
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ted F.A. van Gaalen via swift-evolution]

Oops here it is again: error in example 
On 28.03.2016, at 23:52, Ted F.A. van Gaalen  wrote:

Hello Joanna, seems you are quite new to programming, just kidding, so sad 
you’ve missed the punch card era,
a lot of fun, but I cannot take you back there because my Delorean is broken :o)

Seriously, thank you for writing this, I share your opinion:

> In the light of the preceding paragraphs, I would, respectfully, suggest that 
> "protected" should be allowed for exclusive use in the case of classes that 
> really have to derive from each other, but for no other reason.
Exactly !
> Likewise, "private" should mean what it has meant and still means in most 
> other languages, members of classes only, since, like "protected", that is 
> its true nature.
Yes.
> 
> What Swift presently calls "internal" seems to equate more to the C# concept 
> of "internal" and, in my mind, needs no further discussion or change.
> 
> Just as I was never happy with the Delphi concept of private and protected 
> members being accessible, not just in the class or its derived types, but 
> also from any code in the same code unit, I feel uneasy about the present 
> definition of the private scope in Swift.
> 
Me too.
> I have seen some horrendous abuses of that privileged access, with the 
> gradual growth of single code units to truly gargantuan proportions, just 
> because someone felt that certain classes needed to violate all the rules of 
> common sense and be able to access each others' private parts (if you'll 
> pardon the vernacular).
> 
> 
> 
Especially this, couldn’t agree more:
> Personally, I would like to see the end of the file based scope and, instead, 
> see more clearly defined "privileged" access between types, even if they are 
> in the same code unit.

I would suggest the (true) use of “namespaces”, instead of file based scope,
so that entities  *must*  be imported or qualified by namespace.

When I started with Swift, i was under the false impression that Swift 
concatenates all the sources in a project and simply treat this
as one single source file…

To my knowledge there is no way to hide class members. This is not good !
I’d like to show how i prefer it in this example: 

“private” here means: only visible within the scope where it was declared!  
Imho what private does now in Swift is
completely wrong. 
“Protected” is here: like private but visible in descendants as well 

namespace Eriador
{
class Mithril   // This class is not visible outside the namespace. 

{   // a + b
var a = 0.0 // should not visible outside this class/instance
private var b = 1.0// “private”is the default
public var c = 1.0 // is visible outside the class
protected var d = “My precious…”  // is also visible in descendants

init()
{
forgeRing()
}

// to use this function outside, it should be preceeded
// by a "public" keyword, like it is in Java:

public func stridingToMordor() -> Double
{
return a + b + c
}
}

} // end namespace Eriador

//in another file
#import Foundation

namespace Rohan
{
  #import namespace Eradior

func quest()
 {
   var mi = Mithril()
   mi.a = 10.0  // Error:  “a" and “b" are 
   mi.b = 10.0  // not public members of Mithril  
   mi.c = 12345.67  // ok 

   print(mi.stridingToMordor()) // ok
 }
}

Just my two cents to this ever lasting theme:
can’t see the wood for the trees anymore.
TedvG



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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ted F.A. van Gaalen via swift-evolution]

Hello Joanna, seems you are quite new to programming, just kidding, so sad 
you’ve missed the punch card era,
a lot of fun, but I cannot take you back there because my Delorean is broken :o)

Seriously, thank you for writing this, I share your opinion:

> In the light of the preceding paragraphs, I would, respectfully, suggest that 
> "protected" should be allowed for exclusive use in the case of classes that 
> really have to derive from each other, but for no other reason.
Exactly !
> Likewise, "private" should mean what it has meant and still means in most 
> other languages, members of classes only, since, like "protected", that is 
> its true nature.
Yes.
> 
> What Swift presently calls "internal" seems to equate more to the C# concept 
> of "internal" and, in my mind, needs no further discussion or change.
> 
> Just as I was never happy with the Delphi concept of private and protected 
> members being accessible, not just in the class or its derived types, but 
> also from any code in the same code unit, I feel uneasy about the present 
> definition of the private scope in Swift.
> 
Me too.
> I have seen some horrendous abuses of that privileged access, with the 
> gradual growth of single code units to truly gargantuan proportions, just 
> because someone felt that certain classes needed to violate all the rules of 
> common sense and be able to access each others' private parts (if you'll 
> pardon the vernacular).
> 
> 
> 
Especially this, couldn’t agree more:
> Personally, I would like to see the end of the file based scope and, instead, 
> see more clearly defined "privileged" access between types, even if they are 
> in the same code unit.

I would suggest the (true) use of “namespaces”, instead of file based scope,
so that entities  *must*  be imported or qualified by namespace.

When I started with Swift, i was under the false impression that Swift 
concatenates all the sources in a project and simply treat this
as one single source file…

To my knowledge there is no way to hide class members. This is not good !
I’d like to show how i prefer it in this example: 

“private” here means: only visible within the scope where it was declared!  
Imho what private does now in Swift is
completely wrong. 
“Protected” is here: like private but visible in descendants as well 

namespace Eriador
{
class Mithril   // This class is not visible outside the namespace. 

{   // a + b
var a = 0.0 // should not visible outside this class/instance
private var b = 1.0// “private”is the default
public var c = 1.0 // is visible outside the class
protected var d = “My precious…”  // is also visible in descendants

init()
{
forgeRing()
}

// to use this function outside, it should be preceeded
// by a "public" keyword, like it is in Java:

public func stridingToMordor() -> Double
{
return a + b + c
}
}

} // end namespace Eriador

//in another file
#import Foundation

namespace Rohan
{
  #import namespace Eradior

func quest()
 {
   var mi = Mithril()
   mi.a = 10.0  // Error:  “a" and “b" are 
   mi.b = 10.0  // not public members of Aragorn  
   mi.c = 12345.67  // ok 

   print(ar.stridingToMordor()) // ok
 }
}

Just my two cents to this ever lasting theme:
can’t see the wood for the trees anymore.
TedvG






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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

> On Mar 28, 2016, at 14:23, David Waite  wrote:
> 
> 
>> On Mar 28, 2016, at 2:30 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> P.S. Extensions do make things a little more complicated, but again, there's 
>> almost no precedent here, and pretty much everyone agrees that this new 
>> scope-private access level shouldn't give access to extensions. That also 
>> means there's an option to keep yourself from accidentally accessing 
>> scope-private members in a member type: put the member type in an extension.
> 
> The only example that comes to mind is Ruby, where I can add new methods to 
> an existing class, and those new methods indeed have access to existing 
> ‘private’ methods:
> 
> class A
>   private def foo()
> puts “foo called”
>   end
> end
> 
> A.new.foo() # error
> 
> class A
>   def bar() # add new bar method
> foo()
>   end
> end
> 
> A.new.bar() # prints “foo called”

Yeah, I tried to sweep that under the rug by noting that Ruby's definition of 
"private" didn't match up with either Java-private or current-Swift-private 
anyway, but it's true that someone coming from Ruby might expect this to work.

Jordan

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matt Whiteside via swift-evolution]

If the following parenthesized access keywords are still on the table as an 
option,

> On Mar 27, 2016, at 14:31, Haravikk via swift-evolution 
>  wrote:
> 
>   public  as-is, item is public/exported outside 
> of module
>   private(module) or private  current internal, item is private to 
> this module, would be the default
>   private(file)   current private, item is private to 
> this file
>   private(scope)  new visibility type, item is private to 
> the current scope



I would prefer them over these ones:

public
moduleprivate
fileprivate
private

To my eyes, the parenthesized ones are more readable and understandable.

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

> I *still* don't understand your reasoning here. If a private member can
be used in a member function, and in closures inside that member function,
why can't it be used in a member type?

The simplest answer is that it's the most private access level, and also
one that doesn't create any confusion. We already discussed several times
here whether inner should have access to outer or the other way around.
With this design, the answer is neither.

A longer answer is that if you move a function into a type and make it a
member function, you change the semantics. It's no longer the same
function. If you move the type inside another type, the semantics is the
same. The only difference is that we get shorter names. Also, if you move a
function to be a member function, that changes the class API. If you move a
class to become a nested class, that does not change the outer class API.
Both classes can be used the same way but with different spelling of the
name of the inner class.

Also, I think that the terminology of access level really comes from OOP.
The problem with the current state of things is that it mixes this
terminology with export levels. This proposal makes "private" mean what it
means in OOP and extends it so that it makes sense with Swift extensions.

If we were talking about "scoped" level access, the immediate scope
addition would be wrong. But if we are talking about "private", it's a
different matter.

On Mon, Mar 28, 2016 at 1:38 PM Jordan Rose  wrote:

> I *still* don't understand your reasoning here. If a private member can
> be used in a member function, and in closures inside that member function,
> why can't it be used in a member type?
>
> I don't have a notion of "immediate lexical scope". Nothing else in Swift
> is only visible in the "immediate" level of curly-braces.
>
> (This doesn't mean that everything can *successfully* be referenced from
> an inner scope; for instance, a local type declared in a function cannot
> capture local variables or 'self'. But there's a technical limitation
> there, and even *with* that you still find those names via name lookup.)
>
> I am actively against this form of the proposal (regardless of names) and
> I'm sorry I didn't notice the intent here the first time around.
>
> Jordan
>
>
> On Mar 28, 2016, at 6:06, Ilya Belenkiy via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Matthew, please take a look at my example with functions (it works today).
> In terms of scope, it should be the same with classes. I updated the
> proposal to restrict private to the immediate scope, so with the update, it
> will be Inner. Please take a look at the proposal. I tried to be very clear
> about both the meaning and motivation in the proposal example.
>
> On Mon, Mar 28, 2016 at 8:58 AM Matthew Johnson 
> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Mar 28, 2016, at 6:48 AM, Ilya Belenkiy via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Outer
>>
>>
>> Why Outer?  It looks to me like the enclosing lexical scope is Inner,
>> thus innerVar would *not* be visible in Outer, it would only be visible in
>> Inner.
>>
>>
>> On Mon, Mar 28, 2016 at 7:30 AM Matthew Judge 
>> wrote:
>>
>>> On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy 
>>> wrote:
>>>
 lexical scope is the other way around: "inner" can see "outer". For
 example:

 func f() {
   let outer = 0
  // f cannot use inner
func g() {
let inner = 1
// g can use outer
}
 }


>>> Maybe I'm off in my terminology, but I think my code example matches
>>> what you are saying here (outer is visible to g() but inner is not visible
>>> to f()
>>>
>>>
 It would work the same way for the access level. That said, I'd rather
 not include this in the proposal.

>>>
>>> So as the proposal stands now, what is the scope that innerVar is
>>> visible to in the following code: Inner or Outer?
>>>
>>> class Outer {
>>> class Inner {
>>> private var innerVar: Int
>>> }
>>> }
>>>
>>>
 The only change that the core team requested was the name changes. I
 personally would prefer a completely private version where you cannot
 inject a class into a scope to get access to the scope internals, but it's
 an edge case that could be argued either way, and I don't want to start
 another lengthy discussion. We already had quite a few.

 On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge 
 wrote:

> I know it was suggested that it be the subject of a different thread,
> but it might be good to clarify how the new private is going to work (or 
> at
> least what is currently envisioned).
>
> My understanding is that the new private would be:
> - visible only to the immediately enclosing scope
> - including the scope of a inner nested scope
> 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Johnson via swift-evolution]

Jordan, I agree with you.  IMO this is a change to the proposal that was not 
requested by the core team.  The meaning of private was accepted was clearly 
the traditional meaning of lexical scope, which cleanly follows the nesting of 
scopes used by the other access control modifiers.  

The modified proposal should only change the declaration modifiers used, not 
any semantics.  If anyone, including Ilya, wants to introduce more “exotic” 
semantics this should be done in a new proposal that starts the process from 
the beginning.


> On Mar 28, 2016, at 12:38 PM, Jordan Rose  wrote:
> 
> I still don't understand your reasoning here. If a private member can be used 
> in a member function, and in closures inside that member function, why can't 
> it be used in a member type?
> 
> I don't have a notion of "immediate lexical scope". Nothing else in Swift is 
> only visible in the "immediate" level of curly-braces.
> 
> (This doesn't mean that everything can successfully be referenced from an 
> inner scope; for instance, a local type declared in a function cannot capture 
> local variables or 'self'. But there's a technical limitation there, and even 
> with that you still find those names via name lookup.)
> 
> I am actively against this form of the proposal (regardless of names) and I'm 
> sorry I didn't notice the intent here the first time around.
> 
> Jordan
> 
> 
>> On Mar 28, 2016, at 6:06, Ilya Belenkiy via swift-evolution 
>> > wrote:
>> 
>> Matthew, please take a look at my example with functions (it works today). 
>> In terms of scope, it should be the same with classes. I updated the 
>> proposal to restrict private to the immediate scope, so with the update, it 
>> will be Inner. Please take a look at the proposal. I tried to be very clear 
>> about both the meaning and motivation in the proposal example.
>> 
>> On Mon, Mar 28, 2016 at 8:58 AM Matthew Johnson > > wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> On Mar 28, 2016, at 6:48 AM, Ilya Belenkiy via swift-evolution 
>> > wrote:
>> 
>>> Outer
>> 
>> Why Outer?  It looks to me like the enclosing lexical scope is Inner, thus 
>> innerVar would *not* be visible in Outer, it would only be visible in Inner.
>> 
>>> 
>>> On Mon, Mar 28, 2016 at 7:30 AM Matthew Judge >> > wrote:
>>> On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy >> > wrote:
>>> lexical scope is the other way around: "inner" can see "outer". For example:
>>> 
>>> func f() {
>>>   let outer = 0
>>>  // f cannot use inner
>>>func g() {
>>>let inner = 1
>>>// g can use outer
>>>}
>>> }
>>> 
>>> 
>>> Maybe I'm off in my terminology, but I think my code example matches what 
>>> you are saying here (outer is visible to g() but inner is not visible to f()
>>>  
>>> It would work the same way for the access level. That said, I'd rather not 
>>> include this in the proposal.
>>> 
>>> So as the proposal stands now, what is the scope that innerVar is visible 
>>> to in the following code: Inner or Outer?
>>> 
>>> class Outer {
>>> class Inner {
>>> private var innerVar: Int
>>> }
>>> }
>>>  
>>> The only change that the core team requested was the name changes. I 
>>> personally would prefer a completely private version where you cannot 
>>> inject a class into a scope to get access to the scope internals, but it's 
>>> an edge case that could be argued either way, and I don't want to start 
>>> another lengthy discussion. We already had quite a few.
>>> 
>>> On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge >> > wrote:
>>> I know it was suggested that it be the subject of a different thread, but 
>>> it might be good to clarify how the new private is going to work (or at 
>>> least what is currently envisioned).
>>> 
>>> My understanding is that the new private would be: 
>>> - visible only to the immediately enclosing scope
>>> - including the scope of a inner nested scope
>>> - not including the scope of an outer nested scope
>>> - not visible to an extension 
>>> 
>>> Said in code (all in the same file):
>>> --
>>> class Outer { // Outer visible to module
>>> private var a: Int // visible to Outer, Inner1, & Inner2
>>> 
>>> class Inner1 { // Inner1 visible to module
>>> private var b: Int // visible to Inner1 only
>>> }
>>> private class Inner2 { // visible to Outer & Inner(s)
>>> var c: Int // visible to Outer & Inner(s)
>>> }
>>> }
>>> 
>>> extension Outer { // visible to module
>>> // 'a', 'b', and 'Inner2' NOT visible
>>> }
>>> --
>>> If this is the intended meaning of private, then fileprivate seems to be 
>>> the same as 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

> Would it really make sense to allow extensions in other files to access
fileprivate members/funcs?

no, fileprivate is limited to the specific file in which it is used.

On Mon, Mar 28, 2016 at 1:13 PM Cheyo Ximenez  wrote:

> Let's say that we go with
> public, moduleprivate, fileprivate, scopeprivate
>
> Would it really make sense to allow extensions in other files to access
> fileprivate members/funcs?  The inclusion of the word 'file' in the name
> would make it confusing that extensions have the special power to reach
> into a fileprivate from another file. This almost begs for another access
> like typeprivate (I am not proposing this).
>
> My understating is that scopeprivate came about as a way to deal with
> extensions, perhaps the author needs to look into a way to tag
> methods/members as not extendable or hidden from extensions only. The
> solution would probably be swift specific and it should probably brake out
> from the norm of other languages.
>
>
>
>
>
>
>
> On Mar 28, 2016, at 5:46 AM, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Ilya said:
> > "public", "protected", and "private" have a very well defined meaning
> in OOP. We shouldn't redefine them without a good reason.
>
> I agree. Swift has a scope-based visibility system, not a type-based
> visibility system, but because Swift redefines the terms 'public' and
> 'private', programmers keep getting confused about how they're used in
> Swift.
>
> Over the last few posts, since Chris Lattner proposed switching to:
> 'public, internal, X, private', we've had several new scales proposed. (In
> every scale in this post, there are four terms in order of decreasing
> visibility, with the second term being the default.)
>
> public, external, internal, private.
> public, internal, private, secret.
> external, internal, public, private.
> public, internal, private, secret.
> public, internal, private, local.
>
> At this point, respectfully, I think we can dismiss the idea that
> labelling any given level as 'public' or 'private' is right or obvious.
> Swift is built around clarity at the point of use. 'private' is not as
> clear as you maintain it is.
>
> > Swift allows extensions, so "private" in its standard form doesn't work
> well -- you could just define an extension and get access to anything. The
> scope based private seems to be the most natural extension (pun intended
> :–)).
>
> We're redefining terms from a type-based visibility scale to a scope-based
> visibility scale. I'm not disagreeing that an extension would allow access
> to type-visible symbols and that this might not be the programmer's
> intention, but that 'private' has a clear meaning in OOP and repurposing
> 'private' is not resolving any confusion.
>
> > 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.
>
> As far as I know, it's not an edge case in Swift, it's a non-case. Swift
> doesn't have type-based visibility. Using Swift's system, I do understand
> that you want 'private' to refer to the least-visible level in the
> hierarchy.
>
> However, as has already been pointed out, the scope-visible level is not
> the least-visible conceivable. There's already discussion over whether the
> properties of inner types should be visible to their outer types. If that
> ever made its way to a proposal, would that level become 'private'? I think
> we can agree that another bikeshedding conversation like this would rather
> be avoided.
>
> There's also the possibility of a 'submodule' level. Chris Lattner
> suggested that the 'private(foo.bar)' syntax might be best for this, but I
> don't know what that means - whether 'submodule' would be within the Swift
> hierarchy or not - but it's a possibility for the future.
>
> I'm repeating myself, but: inclusion of the terms 'module', 'file', and
> 'scope' in our symbols is winning out in clarity. None of those terms has
> changed meaning in the entire discussion. The only question is exactly how
> they should be welded to the term 'private'. There've been three
> suggestions for doing this so far and they're all awkward, either because
> they have parentheses or they're conjoined, but they're unambiguous in
> meaning and no-one's suggested any single-word ideas with the same clarity.
>
> public, private(module), private(file) and private(scope).
> public, moduleprivate, fileprivate, scopeprivate.
> public, privatetomodule, privatetofile, privatetoscope.
>
> I'm tempted to go one further, but if you want to ignore that one further,
> skip the next two paragraphs:
>
> Abandon the words 'public' and 'private'. Let's just accept that, together
> with 'protected', these are well-defined terms of type-based visibility in
> OOP which are orthogonal 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jordan Rose via swift-evolution]

I still don't understand your reasoning here. If a private member can be used 
in a member function, and in closures inside that member function, why can't it 
be used in a member type?

I don't have a notion of "immediate lexical scope". Nothing else in Swift is 
only visible in the "immediate" level of curly-braces.

(This doesn't mean that everything can successfully be referenced from an inner 
scope; for instance, a local type declared in a function cannot capture local 
variables or 'self'. But there's a technical limitation there, and even with 
that you still find those names via name lookup.)

I am actively against this form of the proposal (regardless of names) and I'm 
sorry I didn't notice the intent here the first time around.

Jordan


> On Mar 28, 2016, at 6:06, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> Matthew, please take a look at my example with functions (it works today). In 
> terms of scope, it should be the same with classes. I updated the proposal to 
> restrict private to the immediate scope, so with the update, it will be 
> Inner. Please take a look at the proposal. I tried to be very clear about 
> both the meaning and motivation in the proposal example.
> 
> On Mon, Mar 28, 2016 at 8:58 AM Matthew Johnson  > wrote:
> 
> 
> Sent from my iPad
> 
> On Mar 28, 2016, at 6:48 AM, Ilya Belenkiy via swift-evolution 
> > wrote:
> 
>> Outer
> 
> Why Outer?  It looks to me like the enclosing lexical scope is Inner, thus 
> innerVar would *not* be visible in Outer, it would only be visible in Inner.
> 
>> 
>> On Mon, Mar 28, 2016 at 7:30 AM Matthew Judge > > wrote:
>> On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy > > wrote:
>> lexical scope is the other way around: "inner" can see "outer". For example:
>> 
>> func f() {
>>   let outer = 0
>>  // f cannot use inner
>>func g() {
>>let inner = 1
>>// g can use outer
>>}
>> }
>> 
>> 
>> Maybe I'm off in my terminology, but I think my code example matches what 
>> you are saying here (outer is visible to g() but inner is not visible to f()
>>  
>> It would work the same way for the access level. That said, I'd rather not 
>> include this in the proposal.
>> 
>> So as the proposal stands now, what is the scope that innerVar is visible to 
>> in the following code: Inner or Outer?
>> 
>> class Outer {
>> class Inner {
>> private var innerVar: Int
>> }
>> }
>>  
>> The only change that the core team requested was the name changes. I 
>> personally would prefer a completely private version where you cannot inject 
>> a class into a scope to get access to the scope internals, but it's an edge 
>> case that could be argued either way, and I don't want to start another 
>> lengthy discussion. We already had quite a few.
>> 
>> On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge > > wrote:
>> I know it was suggested that it be the subject of a different thread, but it 
>> might be good to clarify how the new private is going to work (or at least 
>> what is currently envisioned).
>> 
>> My understanding is that the new private would be: 
>> - visible only to the immediately enclosing scope
>> - including the scope of a inner nested scope
>> - not including the scope of an outer nested scope
>> - not visible to an extension 
>> 
>> Said in code (all in the same file):
>> --
>> class Outer { // Outer visible to module
>> private var a: Int // visible to Outer, Inner1, & Inner2
>> 
>> class Inner1 { // Inner1 visible to module
>> private var b: Int // visible to Inner1 only
>> }
>> private class Inner2 { // visible to Outer & Inner(s)
>> var c: Int // visible to Outer & Inner(s)
>> }
>> }
>> 
>> extension Outer { // visible to module
>> // 'a', 'b', and 'Inner2' NOT visible
>> }
>> --
>> If this is the intended meaning of private, then fileprivate seems to be the 
>> same as private (private to the enclosing scope... which happens to be the 
>> file).
>> 
>> Something declared "private" at the top level of a file is fileprivate. 
>> There would still need to be a way to reference scopes other than the 
>> immediate one (especially since there is no way to say "private" and mean 
>> moduleprivate), though I think it would strengthen the argument for 
>> something along the lines of "private(file)", since it would even further 
>> reduce the cases where you are spelling something more than just "private"
>> 
>> 
>> On Mar 27, 2016, at 17:31, Haravikk via swift-evolution 
>> > wrote:
>> 
>>> 
 On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution 
 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Cheyo Ximenez via swift-evolution]

Let's say that we go with 
public, moduleprivate, fileprivate, scopeprivate

Would it really make sense to allow extensions in other files to access 
fileprivate members/funcs?  The inclusion of the word 'file' in the name would 
make it confusing that extensions have the special power to reach into a 
fileprivate from another file. This almost begs for another access like 
typeprivate (I am not proposing this).

My understating is that scopeprivate came about as a way to deal with 
extensions, perhaps the author needs to look into a way to tag methods/members 
as not extendable or hidden from extensions only. The solution would probably 
be swift specific and it should probably brake out from the norm of other 
languages. 







> On Mar 28, 2016, at 5:46 AM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> Ilya said:
> > "public", "protected", and "private" have a very well defined meaning in 
> > OOP. We shouldn't redefine them without a good reason.
> 
> I agree. Swift has a scope-based visibility system, not a type-based 
> visibility system, but because Swift redefines the terms 'public' and 
> 'private', programmers keep getting confused about how they're used in Swift.
> 
> Over the last few posts, since Chris Lattner proposed switching to: 'public, 
> internal, X, private', we've had several new scales proposed. (In every scale 
> in this post, there are four terms in order of decreasing visibility, with 
> the second term being the default.)
> 
> public, external, internal, private.
> public, internal, private, secret.
> external, internal, public, private.
> public, internal, private, secret.
> public, internal, private, local.
> 
> At this point, respectfully, I think we can dismiss the idea that labelling 
> any given level as 'public' or 'private' is right or obvious. Swift is built 
> around clarity at the point of use. 'private' is not as clear as you maintain 
> it is.
> 
> > Swift allows extensions, so "private" in its standard form doesn't work 
> > well -- you could just define an extension and get access to anything. The 
> > scope based private seems to be the most natural extension (pun intended 
> > :–)).
> 
> We're redefining terms from a type-based visibility scale to a scope-based 
> visibility scale. I'm not disagreeing that an extension would allow access to 
> type-visible symbols and that this might not be the programmer's intention, 
> but that 'private' has a clear meaning in OOP and repurposing 'private' is 
> not resolving any confusion.
> 
> > 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.
> 
> As far as I know, it's not an edge case in Swift, it's a non-case. Swift 
> doesn't have type-based visibility. Using Swift's system, I do understand 
> that you want 'private' to refer to the least-visible level in the hierarchy.
> 
> However, as has already been pointed out, the scope-visible level is not the 
> least-visible conceivable. There's already discussion over whether the 
> properties of inner types should be visible to their outer types. If that 
> ever made its way to a proposal, would that level become 'private'? I think 
> we can agree that another bikeshedding conversation like this would rather be 
> avoided.
> 
> There's also the possibility of a 'submodule' level. Chris Lattner suggested 
> that the 'private(foo.bar)' syntax might be best for this, but I don't know 
> what that means - whether 'submodule' would be within the Swift hierarchy or 
> not - but it's a possibility for the future.
> 
> I'm repeating myself, but: inclusion of the terms 'module', 'file', and 
> 'scope' in our symbols is winning out in clarity. None of those terms has 
> changed meaning in the entire discussion. The only question is exactly how 
> they should be welded to the term 'private'. There've been three suggestions 
> for doing this so far and they're all awkward, either because they have 
> parentheses or they're conjoined, but they're unambiguous in meaning and 
> no-one's suggested any single-word ideas with the same clarity.
> 
> public, private(module), private(file) and private(scope).
> public, moduleprivate, fileprivate, scopeprivate.
> public, privatetomodule, privatetofile, privatetoscope.
> 
> I'm tempted to go one further, but if you want to ignore that one further, 
> skip the next two paragraphs:
> 
> Abandon the words 'public' and 'private'. Let's just accept that, together 
> with 'protected', these are well-defined terms of type-based visibility in 
> OOP which are orthogonal to Swift's hierarchy, and that redefining them leads 
> to confusion. Embrace 'external' and 'internal' in their places:
> 
> external, internal(module), internal(file), internal(scope).
> external, 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Joanna Carter via swift-evolution]

If I may be so bold, as a programmer with over 25 years of experience, in 
multiple languages…

Although I can see the reasoning behind "redefining" visibility scope for 
Swift, I find myself both agreeing and disagreeing with various aspects.

Apart from Delphi, I've never come across a use of private other than for the 
scope of the immediate class only. Delphi does a similar thing to Swift, in 
that it defines "private" as meaning the scope of the declaring code file until 
Delphi 7, when someone decided it was a good idea (possibly due to user 
requests) to add "strict private" to indicate a "true" private member, visible 
only to the declaring class.

Likewise, at the same time, "strict protected", was added to convey visibility 
only to inherited classes, in addition to "protected", which means roughly the 
same as "private". Thus giving Delphi, in order of visibility, "strict 
private", "strict protected", "private", "protected" and "public". There are 
even ungodly hacks that allow you to access the private fields of a class in 
another unit!!!

However, in Swift, we can declare a lot more types as "private", but 
"protected" really doesn't seem to make sense outside of classes, as there is 
no inheritance for other types like structs and enums.

But, in Swift, we now have the concept of extensions on all types, making 
inheritance less necessary and prompting us towards protocol-based programming, 
where behaviours can be added to any number of types without having to limit 
that type's inheritance from a base type. Now we can define behaviours that can 
apply to classes, structs, enums and, even, basic types such as Int and String.

Take the example of the Visitor Pattern : With strictly typed and statically 
compiled languages, this classically ends up with a system of double dispatch 
between a hierarchy of classes and a hierarchy of visitors.

Objective-C's class categories permit the extension of a class's behaviour 
without the Visitor Pattern but, with danger of dynamic dispatch that a 
"visitation" method may be called when it does not exist in the category. 
Another problem being that categories can only access "public" members of the 
main class because "public" is the only visibility Objective-C understands 
outside of iVars.

Swift's extensions permit the extension of most types (not just classes) so 
that they can implement one or more protocols, ensuring that the protocol(s) 
is/are fully implemented by raising a compiler error if not satisfied.

So, if we are going to bring in visibility specifiers to Swift, with all of its 
wonderful, type-safe, statically compiled code, we have to carefully consider, 
not just the names of the planned scopes but what impact any restrictions may 
have on the use of protocol-oriented programming and the various extensions on 
types that it will engender.

C++ uses the concept of marking certain methods and classes as "friend", so 
that nominated classes have privileged access to otherwise private members of a 
class; maybe this is a worthwhile concept for determining what parts of a type 
can be accessed by an extension?

I am not suggesting "friend" as a name but the need for being able to restrict 
or allow access to certain members of a type when extending it?

In the light of the preceding paragraphs, I would, respectfully, suggest that 
"protected" should be allowed for exclusive use in the case of classes that 
really have to derive from each other, but for no other reason. Likewise, 
"private" should mean what it has meant and still means in most other 
languages, members of classes only, since, like "protected", that is its true 
nature.

What Swift presently calls "internal" seems to equate more to the C# concept of 
"internal" and, in my mind, needs no further discussion or change.

Just as I was never happy with the Delphi concept of private and protected 
members being accessible, not just in the class or its derived types, but also 
from any code in the same code unit, I feel uneasy about the present definition 
of the private scope in Swift.

I have seen some horrendous abuses of that privileged access, with the gradual 
growth of single code units to truly gargantuan proportions, just because 
someone felt that certain classes needed to violate all the rules of common 
sense and be able to access each others' private parts (if you'll pardon the 
vernacular).

If several types really have to be defined in the same unit, then their 
relationship to each other needs defining far more strictly than just to say 
that they have total free reign to interfere where they want.

Personally, I would like to see the end of the file based scope and, instead, 
see more clearly defined "privileged" access between types, even if they are in 
the same code unit.

Let the naysayers (or even the forsayers) commence :-)

Joanna

--
Joanna Carter
Carter Consulting

___
swift-evolution mailing list

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

Matthew, please take a look at my example with functions (it works today).
In terms of scope, it should be the same with classes. I updated the
proposal to restrict private to the immediate scope, so with the update, it
will be Inner. Please take a look at the proposal. I tried to be very clear
about both the meaning and motivation in the proposal example.

On Mon, Mar 28, 2016 at 8:58 AM Matthew Johnson 
wrote:

>
>
> Sent from my iPad
>
> On Mar 28, 2016, at 6:48 AM, Ilya Belenkiy via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Outer
>
>
> Why Outer?  It looks to me like the enclosing lexical scope is Inner, thus
> innerVar would *not* be visible in Outer, it would only be visible in Inner.
>
>
> On Mon, Mar 28, 2016 at 7:30 AM Matthew Judge 
> wrote:
>
>> On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy 
>> wrote:
>>
>>> lexical scope is the other way around: "inner" can see "outer". For
>>> example:
>>>
>>> func f() {
>>>   let outer = 0
>>>  // f cannot use inner
>>>func g() {
>>>let inner = 1
>>>// g can use outer
>>>}
>>> }
>>>
>>>
>> Maybe I'm off in my terminology, but I think my code example matches what
>> you are saying here (outer is visible to g() but inner is not visible to f()
>>
>>
>>> It would work the same way for the access level. That said, I'd rather
>>> not include this in the proposal.
>>>
>>
>> So as the proposal stands now, what is the scope that innerVar is visible
>> to in the following code: Inner or Outer?
>>
>> class Outer {
>> class Inner {
>> private var innerVar: Int
>> }
>> }
>>
>>
>>> The only change that the core team requested was the name changes. I
>>> personally would prefer a completely private version where you cannot
>>> inject a class into a scope to get access to the scope internals, but it's
>>> an edge case that could be argued either way, and I don't want to start
>>> another lengthy discussion. We already had quite a few.
>>>
>>> On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge 
>>> wrote:
>>>
 I know it was suggested that it be the subject of a different thread,
 but it might be good to clarify how the new private is going to work (or at
 least what is currently envisioned).

 My understanding is that the new private would be:
 - visible only to the immediately enclosing scope
 - including the scope of a inner nested scope
 - not including the scope of an outer nested scope
 - not visible to an extension

 Said in code (all in the same file):
 --
 class Outer { // Outer visible to module
 private var a: Int // visible to Outer, Inner1, & Inner2

 class Inner1 { // Inner1 visible to module
 private var b: Int // visible to Inner1 only
 }
 private class Inner2 { // visible to Outer & Inner(s)
 var c: Int // visible to Outer & Inner(s)
 }
 }

 extension Outer { // visible to module
 // 'a', 'b', and 'Inner2' NOT visible
 }
 --
 If this is the intended meaning of private, then fileprivate seems to
 be the same as private (private to the enclosing scope... which happens to
 be the file).

 Something declared "private" at the top level of a file is fileprivate.
 There would still need to be a way to reference scopes other than the
 immediate one (especially since there is no way to say "private" and mean
 moduleprivate), though I think it would strengthen the argument for
 something along the lines of "private(file)", since it would even further
 reduce the cases where you are spelling something more than just "private"


 On Mar 27, 2016, at 17:31, Haravikk via swift-evolution <
 swift-evolution@swift.org> wrote:


 On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution <
 swift-evolution@swift.org> wrote:

 Public
 External (default)
 Internal
 Private


 I still feel like these are still too vague; I’m not sure I like the
 use of external, as public to me is external since it exports outside of
 the module, whereas what you’re proposing is in fact just limited to the
 module itself. I dislike the current internal keyword too, but at least it
 reads as “internal to this module", this is why the more specific terms are
 better like:

 public as-is, item is public/exported outside of module
 private(module) or private current internal, item is private to this
 module, would be the default
 private(file) current private, item is private to this file
 private(scope) new visibility type, item is private to the current
 scope

 Assuming I’m understanding the restriction properly this time =)

 It’s also the easiest method if we do add another visibility later for
 sub-classes 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien via swift-evolution]

Ilya said:
> "public", "protected", and "private" have a very well defined meaning in
OOP. We shouldn't redefine them without a good reason.

I agree. Swift has a scope-based visibility system, not a type-based
visibility system, but because Swift redefines the terms 'public' and
'private', programmers keep getting confused about how they're used in
Swift.

Over the last few posts, since Chris Lattner proposed switching to:
'public, internal, X, private', we've had several new scales proposed. (In
every scale in this post, there are four terms in order of decreasing
visibility, with the second term being the default.)

public, external, internal, private.
public, internal, private, secret.
external, internal, public, private.
public, internal, private, secret.
public, internal, private, local.

At this point, respectfully, I think we can dismiss the idea that labelling
any given level as 'public' or 'private' is right or obvious. Swift is
built around clarity at the point of use. 'private' is not as clear as you
maintain it is.

> Swift allows extensions, so "private" in its standard form doesn't work
well -- you could just define an extension and get access to anything. The
scope based private seems to be the most natural extension (pun intended
:–)).

We're redefining terms from a type-based visibility scale to a scope-based
visibility scale. I'm not disagreeing that an extension would allow access
to type-visible symbols and that this might not be the programmer's
intention, but that 'private' has a clear meaning in OOP and repurposing
'private' is not resolving any confusion.

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

As far as I know, it's not an edge case in Swift, it's a non-case. Swift
doesn't have type-based visibility. Using Swift's system, I do understand
that you want 'private' to refer to the least-visible level in the
hierarchy.

However, as has already been pointed out, the scope-visible level is not
the least-visible conceivable. There's already discussion over whether the
properties of inner types should be visible to their outer types. If that
ever made its way to a proposal, would that level become 'private'? I think
we can agree that another bikeshedding conversation like this would rather
be avoided.

There's also the possibility of a 'submodule' level. Chris Lattner
suggested that the 'private(foo.bar)' syntax might be best for this, but I
don't know what that means - whether 'submodule' would be within the Swift
hierarchy or not - but it's a possibility for the future.

I'm repeating myself, but: inclusion of the terms 'module', 'file', and
'scope' in our symbols is winning out in clarity. None of those terms has
changed meaning in the entire discussion. The only question is exactly how
they should be welded to the term 'private'. There've been three
suggestions for doing this so far and they're all awkward, either because
they have parentheses or they're conjoined, but they're unambiguous in
meaning and no-one's suggested any single-word ideas with the same clarity.

public, private(module), private(file) and private(scope).
public, moduleprivate, fileprivate, scopeprivate.
public, privatetomodule, privatetofile, privatetoscope.

I'm tempted to go one further, but if you want to ignore that one further,
skip the next two paragraphs:

Abandon the words 'public' and 'private'. Let's just accept that, together
with 'protected', these are well-defined terms of type-based visibility in
OOP which are orthogonal to Swift's hierarchy, and that redefining them
leads to confusion. Embrace 'external' and 'internal' in their places:

external, internal(module), internal(file), internal(scope).
external, moduleinternal, fileinternal, scopeinternal.
external, internaltomodule, internaltofile, internaltoscope.

If you ignored that, welcome back.

I hope I've not been too antagonistic about this. I really want Swift to
use terms with clear meaning, and if that breaks code, I want a clean break
that can be easily healed / migrated.

Every suggestion for relabelling this hierarchy, bar 'public, internal,
private, local/scope', breaks code.

Adding the scope-visible level allows for greater control, but I don't
believe module-visible and file-visible levels would be uncommon with its
inclusion, so the terms for all three - all four, really - should be
balanced in their 'ugliness'.

What the proposal as it stands does need to make clear is what would change
and what would be left behind.

If 'internal' is renamed to 'moduleprivate', explicit uses of 'internal'
need to be replaced.

If there are constants, 'global' functions, operators, or anything that can
be defined outside of a scope, their least visible level is fileprivate.
They can never be 

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

after a brief discussion, updated the proposal to limit `private` only to
the immediate scope.
https://github.com/apple/swift-evolution/pull/234

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:
> https://github.com/apple/swift-evolution/pull/234
>
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

That is not clear to me in the proposal.  The proposal states: "When a
function or a property is defined with `private` access modifier, it is
visible only within that lexical scope." The most immediate lexical scope
for innerVar would be Inner.

I'm not advocating either way, just that it be clear in the proposal.

On Mon, Mar 28, 2016 at 7:48 AM, Ilya Belenkiy 
wrote:

> Outer
>
> On Mon, Mar 28, 2016 at 7:30 AM Matthew Judge 
> wrote:
>
>> On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy 
>> wrote:
>>
>>> lexical scope is the other way around: "inner" can see "outer". For
>>> example:
>>>
>>> func f() {
>>>   let outer = 0
>>>  // f cannot use inner
>>>func g() {
>>>let inner = 1
>>>// g can use outer
>>>}
>>> }
>>>
>>>
>> Maybe I'm off in my terminology, but I think my code example matches what
>> you are saying here (outer is visible to g() but inner is not visible to f()
>>
>>
>>> It would work the same way for the access level. That said, I'd rather
>>> not include this in the proposal.
>>>
>>
>> So as the proposal stands now, what is the scope that innerVar is visible
>> to in the following code: Inner or Outer?
>>
>> class Outer {
>> class Inner {
>> private var innerVar: Int
>> }
>> }
>>
>>
>>> The only change that the core team requested was the name changes. I
>>> personally would prefer a completely private version where you cannot
>>> inject a class into a scope to get access to the scope internals, but it's
>>> an edge case that could be argued either way, and I don't want to start
>>> another lengthy discussion. We already had quite a few.
>>>
>>> On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge 
>>> wrote:
>>>
 I know it was suggested that it be the subject of a different thread,
 but it might be good to clarify how the new private is going to work (or at
 least what is currently envisioned).

 My understanding is that the new private would be:
 - visible only to the immediately enclosing scope
 - including the scope of a inner nested scope
 - not including the scope of an outer nested scope
 - not visible to an extension

 Said in code (all in the same file):
 --
 class Outer { // Outer visible to module
 private var a: Int // visible to Outer, Inner1, & Inner2

 class Inner1 { // Inner1 visible to module
 private var b: Int // visible to Inner1 only
 }
 private class Inner2 { // visible to Outer & Inner(s)
 var c: Int // visible to Outer & Inner(s)
 }
 }

 extension Outer { // visible to module
 // 'a', 'b', and 'Inner2' NOT visible
 }
 --
 If this is the intended meaning of private, then fileprivate seems to
 be the same as private (private to the enclosing scope... which happens to
 be the file).

 Something declared "private" at the top level of a file is fileprivate.
 There would still need to be a way to reference scopes other than the
 immediate one (especially since there is no way to say "private" and mean
 moduleprivate), though I think it would strengthen the argument for
 something along the lines of "private(file)", since it would even further
 reduce the cases where you are spelling something more than just "private"


 On Mar 27, 2016, at 17:31, Haravikk via swift-evolution <
 swift-evolution@swift.org> wrote:


 On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution <
 swift-evolution@swift.org> wrote:

 Public
 External (default)
 Internal
 Private


 I still feel like these are still too vague; I’m not sure I like the
 use of external, as public to me is external since it exports outside of
 the module, whereas what you’re proposing is in fact just limited to the
 module itself. I dislike the current internal keyword too, but at least it
 reads as “internal to this module", this is why the more specific terms are
 better like:

 public as-is, item is public/exported outside of module
 private(module) or private current internal, item is private to this
 module, would be the default
 private(file) current private, item is private to this file
 private(scope) new visibility type, item is private to the current
 scope

 Assuming I’m understanding the restriction properly this time =)

 It’s also the easiest method if we do add another visibility later for
 sub-classes such as private(type), as it doesn’t even require a new 
 keyword.

 ___


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


___

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

Maybe it's good thing that we just discussed it. After replying to Matthew,
this meaning private feels so wrong that I will update  the proposal
to disallow this. Private should mean private.

On Mon, Mar 28, 2016 at 7:27 AM Brent Royal-Gordon 
wrote:

> > We already had a very long discussion about all of these topics.
>
> I am not suggesting you change the design. I am suggesting you clarify the
> description of your existing design so that everyone understands what it
> means, because confusion is rampant.
>
> > 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.
>
>
> So what you're saying is, you are purposefully writing the proposal
> vaguely so that everyone can assume it says whatever they imagine it says,
> and thus more people will support the proposal?
>
> This is no way to design a programming language.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

The proposal is not vague. Most questions / misunderstanding is not due to
the proposal itself but due to how these terms are used in other languages.

It does have one unintended conclusion (the potential class injection to
get access). My position on it is not to change it because it's an edge
case that some people want and that makes the design simpler and more
consistent with the terms that it uses (scope).

If my proposal was to disallow adding an inner class to gain access to
outer class, I'd make it explicit. But I am not proposing it, so there
doesn't seem to be a need to include it and cause more confusion (we
already had plenty of emails about the most common use cases). Also, the
core team did not request a clarification on this, so I think it is clear
to anybody who wants to go to that level of detail.

On Mon, Mar 28, 2016 at 7:27 AM Brent Royal-Gordon 
wrote:

> > We already had a very long discussion about all of these topics.
>
> I am not suggesting you change the design. I am suggesting you clarify the
> description of your existing design so that everyone understands what it
> means, because confusion is rampant.
>
> > 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.
>
>
> So what you're saying is, you are purposefully writing the proposal
> vaguely so that everyone can assume it says whatever they imagine it says,
> and thus more people will support the proposal?
>
> This is no way to design a programming language.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

On Mon, Mar 28, 2016 at 6:41 AM, Ilya Belenkiy 
wrote:

> lexical scope is the other way around: "inner" can see "outer". For
> example:
>
> func f() {
>   let outer = 0
>  // f cannot use inner
>func g() {
>let inner = 1
>// g can use outer
>}
> }
>
>
Maybe I'm off in my terminology, but I think my code example matches what
you are saying here (outer is visible to g() but inner is not visible to f()


> It would work the same way for the access level. That said, I'd rather not
> include this in the proposal.
>

So as the proposal stands now, what is the scope that innerVar is visible
to in the following code: Inner or Outer?

class Outer {
class Inner {
private var innerVar: Int
}
}


> The only change that the core team requested was the name changes. I
> personally would prefer a completely private version where you cannot
> inject a class into a scope to get access to the scope internals, but it's
> an edge case that could be argued either way, and I don't want to start
> another lengthy discussion. We already had quite a few.
>
> On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge 
> wrote:
>
>> I know it was suggested that it be the subject of a different thread, but
>> it might be good to clarify how the new private is going to work (or at
>> least what is currently envisioned).
>>
>> My understanding is that the new private would be:
>> - visible only to the immediately enclosing scope
>> - including the scope of a inner nested scope
>> - not including the scope of an outer nested scope
>> - not visible to an extension
>>
>> Said in code (all in the same file):
>> --
>> class Outer { // Outer visible to module
>> private var a: Int // visible to Outer, Inner1, & Inner2
>>
>> class Inner1 { // Inner1 visible to module
>> private var b: Int // visible to Inner1 only
>> }
>> private class Inner2 { // visible to Outer & Inner(s)
>> var c: Int // visible to Outer & Inner(s)
>> }
>> }
>>
>> extension Outer { // visible to module
>> // 'a', 'b', and 'Inner2' NOT visible
>> }
>> --
>> If this is the intended meaning of private, then fileprivate seems to be
>> the same as private (private to the enclosing scope... which happens to be
>> the file).
>>
>> Something declared "private" at the top level of a file is fileprivate.
>> There would still need to be a way to reference scopes other than the
>> immediate one (especially since there is no way to say "private" and mean
>> moduleprivate), though I think it would strengthen the argument for
>> something along the lines of "private(file)", since it would even further
>> reduce the cases where you are spelling something more than just "private"
>>
>>
>> On Mar 27, 2016, at 17:31, Haravikk via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Public
>> External (default)
>> Internal
>> Private
>>
>>
>> I still feel like these are still too vague; I’m not sure I like the use
>> of external, as public to me is external since it exports outside of the
>> module, whereas what you’re proposing is in fact just limited to the module
>> itself. I dislike the current internal keyword too, but at least it reads
>> as “internal to this module", this is why the more specific terms are
>> better like:
>>
>> public as-is, item is public/exported outside of module
>> private(module) or private current internal, item is private to this
>> module, would be the default
>> private(file) current private, item is private to this file
>> private(scope) new visibility type, item is private to the current scope
>>
>> Assuming I’m understanding the restriction properly this time =)
>>
>> It’s also the easiest method if we do add another visibility later for
>> sub-classes such as private(type), as it doesn’t even require a new keyword.
>>
>> ___
>>
>>
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

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

> > I created a pull request with the updated proposal:
> > https://github.com/apple/swift-evolution/pull/234
>
> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

I understand the analogy, but I think that it doesn't apply here. If Swift
was 30 years old, the argument would work, but right now there are many
more people in the world who use the terms differently. Originally, I
suggested using another name for backward compatibility, but I am glad that
the core team decided to use the standard names.

On Fri, Mar 25, 2016 at 9:57 PM Ross O'Brien 
wrote:

> The specific meaning of 'public' and 'private' in programming languages
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent
> to Swift's 'public'. Swift has no equivalent to their 'private'.
>
> Possibly my familiarity with other languages isn't broad enough, but this
> is why I haven't understood the idea that Swift's use of 'private' is
> "right" or "obvious". You learn Swift's meanings of these terms by coding
> in Swift, you don't learn these meanings anywhere else first.
>
> To use a hopefully recognised example: an American who wants 'chips' wants
> what a Brit calls crisps; a Brit who wants chips wants what an American
> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the
> one you grew up with.
>
> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > all of these names (public, internal, private, local) have specific
>> meaning in the context of computer languages.
>>
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's
>> an access level. It usually has something to do with declaring variables
>> inside a function.
>>
>> For instance, Perl uses it to back up and restore a global variable. ML
>> uses it to create a scope (roughly). Lua and Julia use it to declare
>> lexical variables which are visible in enclosed scopes, which SE-0025's new
>> access level is specifically *not* supposed to allow.
>>
>> I don't know of any language where `local` is used as an access level. If
>> you're aware of an analogous use in another language, I'd be interested to
>> see it. But the examples I've found if anything *undermine* the suggestion
>> that `local` would be a good keyword choice.
>>
>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

"public", "protected", and "private" have a very well defined meaning in
OOP. We shouldn't redefine them without a good reason.

Swift allows extensions, so "private" in its standard form doesn't work
well -- you could just define an extension and get access to anything. The
scope based private seems to be the most natural extension (pun intended
:–)).

On Sat, Mar 26, 2016 at 3:14 AM Cheyo Ximenez  wrote:

> I agree with Ross. Swift already redefined the common access modifiers
> meanings.
> Why not use the word 'protected' to mean 'local'?
>
> public
> internal
> private
> protected // Java got it wrong. :) This is "protected" against extensions.
>
>
> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The specific meaning of 'public' and 'private' in programming languages
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent
> to Swift's 'public'. Swift has no equivalent to their 'private'.
>
> Possibly my familiarity with other languages isn't broad enough, but this
> is why I haven't understood the idea that Swift's use of 'private' is
> "right" or "obvious". You learn Swift's meanings of these terms by coding
> in Swift, you don't learn these meanings anywhere else first.
>
> To use a hopefully recognised example: an American who wants 'chips' wants
> what a Brit calls crisps; a Brit who wants chips wants what an American
> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the
> one you grew up with.
>
> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > all of these names (public, internal, private, local) have specific
>> meaning in the context of computer languages.
>>
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's
>> an access level. It usually has something to do with declaring variables
>> inside a function.
>>
>> For instance, Perl uses it to back up and restore a global variable. ML
>> uses it to create a scope (roughly). Lua and Julia use it to declare
>> lexical variables which are visible in enclosed scopes, which SE-0025's new
>> access level is specifically *not* supposed to allow.
>>
>> I don't know of any language where `local` is used as an access level. If
>> you're aware of an analogous use in another language, I'd be interested to
>> see it. But the examples I've found if anything *undermine* the suggestion
>> that `local` would be a good keyword choice.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

this is more in line with other naming conventions, but the names in the
updated proposal seem to match the closest to everything else in Swift. I
waited for about a week to get everyone's opinion, but I think that we are
past the name discussions at this point.

On Sun, Mar 27, 2016 at 11:50 PM Matthew Judge via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > 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:
> >> 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  wrote:
> >> I like fileprivate, if that’s the only change. On the other hand, if we
> want to consider a broader change, what about:
> >>
> >>privatesymbol 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 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

lexical scope is the other way around: "inner" can see "outer". For example:

func f() {
  let outer = 0
 // f cannot use inner
   func g() {
   let inner = 1
   // g can use outer
   }
}

It would work the same way for the access level. That said, I'd rather not
include this in the proposal. The only change that the core team requested
was the name changes. I personally would prefer a completely private
version where you cannot inject a class into a scope to get access to the
scope internals, but it's an edge case that could be argued either way, and
I don't want to start another lengthy discussion. We already had quite a
few.

On Sun, Mar 27, 2016 at 11:17 PM Matthew Judge 
wrote:

> I know it was suggested that it be the subject of a different thread, but
> it might be good to clarify how the new private is going to work (or at
> least what is currently envisioned).
>
> My understanding is that the new private would be:
> - visible only to the immediately enclosing scope
> - including the scope of a inner nested scope
> - not including the scope of an outer nested scope
> - not visible to an extension
>
> Said in code (all in the same file):
> --
> class Outer { // Outer visible to module
> private var a: Int // visible to Outer, Inner1, & Inner2
>
> class Inner1 { // Inner1 visible to module
> private var b: Int // visible to Inner1 only
> }
> private class Inner2 { // visible to Outer & Inner(s)
> var c: Int // visible to Outer & Inner(s)
> }
> }
>
> extension Outer { // visible to module
> // 'a', 'b', and 'Inner2' NOT visible
> }
> --
> If this is the intended meaning of private, then fileprivate seems to be
> the same as private (private to the enclosing scope... which happens to be
> the file).
>
> Something declared "private" at the top level of a file is fileprivate.
> There would still need to be a way to reference scopes other than the
> immediate one (especially since there is no way to say "private" and mean
> moduleprivate), though I think it would strengthen the argument for
> something along the lines of "private(file)", since it would even further
> reduce the cases where you are spelling something more than just "private"
>
>
> On Mar 27, 2016, at 17:31, Haravikk via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Public
> External (default)
> Internal
> Private
>
>
> I still feel like these are still too vague; I’m not sure I like the use
> of external, as public to me is external since it exports outside of the
> module, whereas what you’re proposing is in fact just limited to the module
> itself. I dislike the current internal keyword too, but at least it reads
> as “internal to this module", this is why the more specific terms are
> better like:
>
> public as-is, item is public/exported outside of module
> private(module) or private current internal, item is private to this
> module, would be the default
> private(file) current private, item is private to this file
> private(scope) new visibility type, item is private to the current scope
>
> Assuming I’m understanding the restriction properly this time =)
>
> It’s also the easiest method if we do add another visibility later for
> sub-classes such as private(type), as it doesn’t even require a new keyword.
>
> ___
>
>
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

> On Mar 24, 2016, at 01:13, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
> 
>> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution 
>>  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  wrote:
>> I like fileprivate, if that’s the only change. On the other hand, if we want 
>> to consider a broader change, what about:
>> 
>>privatesymbol 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 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution 
>>  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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Matthew Judge via swift-evolution]

I know it was suggested that it be the subject of a different thread, but it 
might be good to clarify how the new private is going to work (or at least what 
is currently envisioned).

My understanding is that the new private would be: 
- visible only to the immediately enclosing scope
- including the scope of a inner nested scope
- not including the scope of an outer nested scope
- not visible to an extension 

Said in code (all in the same file):
--
class Outer { // Outer visible to module
private var a: Int // visible to Outer, Inner1, & Inner2

class Inner1 { // Inner1 visible to module
private var b: Int // visible to Inner1 only
}
private class Inner2 { // visible to Outer & Inner(s)
var c: Int // visible to Outer & Inner(s)
}
}

extension Outer { // visible to module
// 'a', 'b', and 'Inner2' NOT visible
}
--
If this is the intended meaning of private, then fileprivate seems to be the 
same as private (private to the enclosing scope... which happens to be the 
file).

Something declared "private" at the top level of a file is fileprivate. There 
would still need to be a way to reference scopes other than the immediate one 
(especially since there is no way to say "private" and mean moduleprivate), 
though I think it would strengthen the argument for something along the lines 
of "private(file)", since it would even further reduce the cases where you are 
spelling something more than just "private"


> On Mar 27, 2016, at 17:31, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 27 Mar 2016, at 19:34, Jose Cheyo Jimenez via swift-evolution 
>>  wrote:
>> 
>> Public 
>> External (default)
>> Internal
>> Private
> 
> I still feel like these are still too vague; I’m not sure I like the use of 
> external, as public to me is external since it exports outside of the module, 
> whereas what you’re proposing is in fact just limited to the module itself. I 
> dislike the current internal keyword too, but at least it reads as “internal 
> to this module", this is why the more specific terms are better like:
> 
>   public  as-is, item is public/exported outside 
> of module
>   private(module) or private  current internal, item is private to 
> this module, would be the default
>   private(file)   current private, item is private to 
> this file
>   private(scope)  new visibility type, item is private to 
> the current scope
> 
> Assuming I’m understanding the restriction properly this time =)
> 
> It’s also the easiest method if we do add another visibility later for 
> sub-classes such as private(type), as it doesn’t even require a new keyword.
> ___
> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Brent Royal-Gordon via swift-evolution]

> I created a pull request with the updated proposal:
> https://github.com/apple/swift-evolution/pull/234

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

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy via swift-evolution]

I created a pull request with the updated proposal:
https://github.com/apple/swift-evolution/pull/234

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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Maximilian Hünenberger via swift-evolution]

I like the idea of protected (against extensions).
However this raises the question whether extensions are also extensions of 
scope.


Can "private(scope)" properties/functions be accessed from extensions?


In your case:
Is "protected" exactly like local? So it doesn't hide properties from 
extensions within the file?
By making "private" scope based it is less private than "protected" which 
doesn't feel right to me. (Assuming extensions extend scope)

In my opinion "protected" should protect against other scopes/classes. Leaving 
"private" file based.


Kind regards
- Maximilian

> Am 26.03.2016 um 08:14 schrieb Cheyo Ximenez via swift-evolution 
> :
> 
> I agree with Ross. Swift already redefined the common access modifiers 
> meanings. 
> Why not use the word 'protected' to mean 'local'?
> 
> public
> internal
> private
> protected // Java got it wrong. :) This is "protected" against extensions.  
> 
>> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution 
>>  wrote:
>> 
>> The specific meaning of 'public' and 'private' in programming languages 
>> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
>> Objective C; their 'public' is Swift's 'internal'. They have no equivalent 
>> to Swift's 'public'. Swift has no equivalent to their 'private'.
>> 
>> Possibly my familiarity with other languages isn't broad enough, but this is 
>> why I haven't understood the idea that Swift's use of 'private' is "right" 
>> or "obvious". You learn Swift's meanings of these terms by coding in Swift, 
>> you don't learn these meanings anywhere else first.
>> 
>> To use a hopefully recognised example: an American who wants 'chips' wants 
>> what a Brit calls crisps; a Brit who wants chips wants what an American 
>> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the 
>> one you grew up with.
>> 
>>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> > all of these names (public, internal, private, local) have specific 
>>> > meaning in the context of computer languages.
>>> 
>>> Yes, `local` has a meaning, but that meaning is generally *not* that it's 
>>> an access level. It usually has something to do with declaring variables 
>>> inside a function.
>>> 
>>> For instance, Perl uses it to back up and restore a global variable. ML 
>>> uses it to create a scope (roughly). Lua and Julia use it to declare 
>>> lexical variables which are visible in enclosed scopes, which SE-0025's new 
>>> access level is specifically *not* supposed to allow.
>>> 
>>> I don't know of any language where `local` is used as an access level. If 
>>> you're aware of an analogous use in another language, I'd be interested to 
>>> see it. But the examples I've found if anything *undermine* the suggestion 
>>> that `local` would be a good keyword choice.
>>> 
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Haravikk via swift-evolution]

> On 26 Mar 2016, at 14:11, Ross O'Brien  wrote:
> 
> Haravikk: private (type) would be the subject of another proposal.
> 
> What this proposal is about is the following (all in one file):
> 
> struct Foo {
> func doThing() {
> doPrivateThing()
> }
> 
> private func doPrivateThing() { }
> }
> 
> extension Foo {
> func doOtherThing() {
> doPrivateThing()
> }
> 
> private func doPrivateThing() { }
> }
> 
> There would be two functions called doPrivateThing(). The first is private to 
> the struct declaration; the second to the extension. There's no conflict 
> between them.

I wasn’t actually trying to propose a new form of visibility, but the keyword 
discussion keeps coming up on various types of visibility so I guess I’m just 
getting confused with my terminology in these cases. My point was to re-raise 
the private(foo) style rather than cover some other type of visibility. It also 
doesn’t help that everyone has different names on what everything should named, 
but then that’s partly the point I was trying to make =D

> The reason we continue to have confusion about this (I'm guilty of this too) 
> is because "private" has a standard meaning in many languages and a 
> non-standard meaning in Swift.
> 
> Chris Lattner's explained the reasoning about conjoined keywords in a few 
> places I think, but the posts from this thread are here:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013261.html
>  
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013439.html
>  
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013463.html
>  
> 
Thanks for linking these, but I really don’t like any of the proposed conjoined 
keywords any more than I like the suggested single-word alternatives, which is 
why I really feel that the parenthesised restriction is a much better style, as 
we can argue forever on what the best new visibility keywords and nothing will 
be good enough IMO. The parenthesised style however means that we not only 
avoid keyword bloat, we would actually remove one, plus we get the same benefit 
to clarity of having two-word visibility without the nastiness of the various 
conjoined options I’ve seen so far.

Other than it being “weird and awkward” I don’t see any real reasons why we 
can’t just the private(foo) style; it’s not really more awkward than a 
conjoined keyword, and I think that the logical grouping is worth it being a 
bit different. In fact, in the first linked post Chris points out that well 
chosen public/private defaults should be all that most people need, so you only 
need the parenthesis for the more unusual cases which I think makes it ideal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jose Cheyo Jimenez via swift-evolution]

+1 for this. The only reason I was thinking 'external' was because 'module' 
seems to clash with the identity of the actual module but i am for the order 
and introducing a new word for module access. 


> On Mar 14, 2016, at 7: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 
>>  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 
>>>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Jose Cheyo Jimenez via swift-evolution]

The word 'external' is growing on me but as the (module access). 

public (unchanged)
external (module access)
internal (file access)
private (scoped access)

module access = has external access from other files in the module. 
file access = has internal access to current file
scope access = has only access to the current scope. 

Private will align with other languages definition of private. 
I don't think public should change and I don't like all the others to be called 
private(levelofprivacy).




> On Mar 25, 2016, at 7:32 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> I'll throw another suggestion into the ring:
> 
> private (scoped access)
> public (file access)
> internal (module access)
> external (infinity and beyond)
> 
> l8r
> Sean
> 
> Sent from my iPad
> 
>> On Mar 25, 2016, at 8:57 PM, Ross O'Brien via swift-evolution 
>>  wrote:
>> 
>> The specific meaning of 'public' and 'private' in programming languages 
>> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
>> Objective C; their 'public' is Swift's 'internal'. They have no equivalent 
>> to Swift's 'public'. Swift has no equivalent to their 'private'.
>> 
>> Possibly my familiarity with other languages isn't broad enough, but this is 
>> why I haven't understood the idea that Swift's use of 'private' is "right" 
>> or "obvious". You learn Swift's meanings of these terms by coding in Swift, 
>> you don't learn these meanings anywhere else first.
>> 
>> To use a hopefully recognised example: an American who wants 'chips' wants 
>> what a Brit calls crisps; a Brit who wants chips wants what an American 
>> calls french fries. Which meaning of 'chips' is more intuitive? Answer: the 
>> one you grew up with.
>> 
>>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> > all of these names (public, internal, private, local) have specific 
>>> > meaning in the context of computer languages.
>>> 
>>> Yes, `local` has a meaning, but that meaning is generally *not* that it's 
>>> an access level. It usually has something to do with declaring variables 
>>> inside a function.
>>> 
>>> For instance, Perl uses it to back up and restore a global variable. ML 
>>> uses it to create a scope (roughly). Lua and Julia use it to declare 
>>> lexical variables which are visible in enclosed scopes, which SE-0025's new 
>>> access level is specifically *not* supposed to allow.
>>> 
>>> I don't know of any language where `local` is used as an access level. If 
>>> you're aware of an analogous use in another language, I'd be interested to 
>>> see it. But the examples I've found if anything *undermine* the suggestion 
>>> that `local` would be a good keyword choice.
>>> 
>>> --
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Cheyo Ximenez via swift-evolution]

I agree with Ross. Swift already redefined the common access modifiers 
meanings. 
Why not use the word 'protected' to mean 'local'?

public
internal
private
protected // Java got it wrong. :) This is "protected" against extensions.  

> On Mar 25, 2016, at 6:57 PM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> The specific meaning of 'public' and 'private' in programming languages 
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent to 
> Swift's 'public'. Swift has no equivalent to their 'private'.
> 
> Possibly my familiarity with other languages isn't broad enough, but this is 
> why I haven't understood the idea that Swift's use of 'private' is "right" or 
> "obvious". You learn Swift's meanings of these terms by coding in Swift, you 
> don't learn these meanings anywhere else first.
> 
> To use a hopefully recognised example: an American who wants 'chips' wants 
> what a Brit calls crisps; a Brit who wants chips wants what an American calls 
> french fries. Which meaning of 'chips' is more intuitive? Answer: the one you 
> grew up with.
> 
>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> > all of these names (public, internal, private, local) have specific 
>> > meaning in the context of computer languages.
>> 
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's an 
>> access level. It usually has something to do with declaring variables inside 
>> a function.
>> 
>> For instance, Perl uses it to back up and restore a global variable. ML uses 
>> it to create a scope (roughly). Lua and Julia use it to declare lexical 
>> variables which are visible in enclosed scopes, which SE-0025's new access 
>> level is specifically *not* supposed to allow.
>> 
>> I don't know of any language where `local` is used as an access level. If 
>> you're aware of an analogous use in another language, I'd be interested to 
>> see it. But the examples I've found if anything *undermine* the suggestion 
>> that `local` would be a good keyword choice.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

[Sean Heber via swift-evolution]

I'll throw another suggestion into the ring:

private (scoped access)
public (file access)
internal (module access)
external (infinity and beyond)

l8r
Sean

Sent from my iPad

> On Mar 25, 2016, at 8:57 PM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> The specific meaning of 'public' and 'private' in programming languages 
> refers to type-based symbol visibility. I'm thinking of C++, C#, Java and 
> Objective C; their 'public' is Swift's 'internal'. They have no equivalent to 
> Swift's 'public'. Swift has no equivalent to their 'private'.
> 
> Possibly my familiarity with other languages isn't broad enough, but this is 
> why I haven't understood the idea that Swift's use of 'private' is "right" or 
> "obvious". You learn Swift's meanings of these terms by coding in Swift, you 
> don't learn these meanings anywhere else first.
> 
> To use a hopefully recognised example: an American who wants 'chips' wants 
> what a Brit calls crisps; a Brit who wants chips wants what an American calls 
> french fries. Which meaning of 'chips' is more intuitive? Answer: the one you 
> grew up with.
> 
>> On Sat, Mar 26, 2016 at 1:10 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> > all of these names (public, internal, private, local) have specific 
>> > meaning in the context of computer languages.
>> 
>> Yes, `local` has a meaning, but that meaning is generally *not* that it's an 
>> access level. It usually has something to do with declaring variables inside 
>> a function.
>> 
>> For instance, Perl uses it to back up and restore a global variable. ML uses 
>> it to create a scope (roughly). Lua and Julia use it to declare lexical 
>> variables which are visible in enclosed scopes, which SE-0025's new access 
>> level is specifically *not* supposed to allow.
>> 
>> I don't know of any language where `local` is used as an access level. If 
>> you're aware of an analogous use in another language, I'd be interested to 
>> see it. But the examples I've found if anything *undermine* the suggestion 
>> that `local` would be a good keyword choice.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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