`moduleprivate` is the default value. I doubt it will get used much if at all. I don't think `fileprivate` will get used much either
but in such cases, I think those seven extra letters are essential and documenting.
The two remaining public and private access levels are simple and intuitively obvious.
-- E
···
On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
I think it does. `module` could mean many things related to how Swift creates and consumes modules.
`moduleprivate` combines something about access levels (public/private) and scope (module), is easy to
Google, offers few "wrong" interpretations. By using a longer keyword, it is less flexible in meaning and
more fixed in purpose.
Sure, but is that worth 7 to 9 extra characters at every single use site for something that's actually pretty common? Is it worth the muddled mess of an all-lowercase keyword with no obvious break, or the attention-grabbing of a capital letter or an underscore?
`module` and `file` are not going to be obscure corners of the language. Most people will probably learn about them at the same time they learn about `public` and `private`.
(Actually, if `module` continues to be the default, you probably won't see it *that* often. You *will* see `file`, but that's the one that can't be as easily confused with a declaration.)
Obviousness for new users is great, but you can take it too far. We call the type `Int32`, not `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and if we did, it's not clear the longer name would really be more obvious, because it would be such a pain to read.
Thanks for the explanation. I think this last part gets at the heart of my question: Why isn't it important to highlight word boundaries in this case?
Swift is an “opinionated” language and we find snake case to be ugly (YMMV of course).
My attempt to summarize/rephrase the overall answer: "We used up all the word-boundary-highlighting conventions that we don't find ugly on other parts of the language, and we don't want to reuse any of them due to the potential for conflict and confusion.”
I’m sorry for the confusion. There are two issues: whether it is important to highlight word boundaries, and if so, what approach to use. The first (and longer) part of the email was intended to justify why we don’t highlight word boundaries for keywords. My overly snarky answer at the end was an attempt to answer why we don’t use snake case, but it wasn’t very effective :-)
Here is a different way to look at it: if we were going to highlight word boundaries, we would do it with camel case. We use camel case in other places, and it has advantages over snake case (shorter identifiers), so we wouldn’t introduce a new way to do it.
As for snake case being ugly, my mileage does vary (obviously). Ithink thereadability costofnot highlightingwordboundaries outweighsthe aestheticconcerns. But them's the breaks when it comes to aesthetic issues, I suppose. And in the grand scheme of things, at least the total number of declaration modifiers should be small… :)
I understand the concern. The short version of the argument is that multiword keywords and declmodifiers are rare , primitive, and used in idiomatic ways so the opportunity for confusion is low.
-Chris
···
On Mar 25, 2016, at 6:34 AM, John Siracusa via swift-evolution <swift-evolution@swift.org> wrote:
On Fri, Mar 25, 2016 at 1:24 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
Sure, but is that worth 7 to 9 extra characters at every single use site for something that's actually pretty common?
Yes.
These are special cases — both file-private and module-private is something that is fairly unusual and should stick out a bit, so the length helps here. (Unless you're writing your entire app in module-private mode, in which case you won't use the modifier at all.)
I think Chris has explicitly stated that brevity for the sake of typing less is not a goal of Swift. There's software like Keyboard Maestro that I really recommend when typing code; just assign keyboard shortcuts (GW-BASIC-style) to the common keywords, and the length won't matter.
We call the type `Int32`, not `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`
Perhaps the new modifiers look worse to you than to me. "fileprivate var" reads just fine to my ears, exactly the right balance of length and brevity, and "file var" invokes wrong associations in my head, akin to being a static var, and generally feels way too short.
no, I still want extensions to be able to hide their implementation details
from anything else (including other extensions of the same type or the
"root" class definition). And I also want to be able to hide stuff in the
root class definition from extensions of the same type. I just don't want
an ability to inject new class in a scope to get access to its
implementation details.
That said, I will not include it in the updated proposal (i'll only update
the names) and will start a new thread after SE-0025. Also, I think that
it's an edge case, and it could be argued either way.
···
On Thu, Mar 24, 2016 at 11:47 AM Matthew Johnson <matthew@anandabits.com> wrote:
On Mar 24, 2016, at 10:40 AM, Ilya Belenkiy via swift-evolution < > swift-evolution@swift.org> wrote:
This is why I'd like private to mean exactly that (no nested class should
get access). Then the meaning is clear: it's as private as it can be :-)
In that case, you want a type-based access control mechanism, not a
scope-based access control mechanism. Your proposal that was provisionally
accepted is for a scope-based mechanism.
Chris’s request for bikeshedding on names did not include a request to
bikeshed on semantics. Any discussion about type-based access control
should happen in a different thread IMO.
Private and public have well defined meaning. We
On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution < > swift-evolution@swift.org> wrote:
I agree that 'private' still feels too subjective on its own. It's
intuitively 'not public'; it's not intuitively the access term for
'declaration only'.
I'm not opposed to fileprivate and moduleprivate, if we like those terms.
I'd just prefer a corresponding scopeprivate or declarationprivate.
On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution < >> swift-evolution@swift.org> wrote:
> How about we continue this trend, and follow other existing Swift
keywords that merge two lowercase words (associatedtype, typealias, etc),
and use:
>
> public
> moduleprivate
> fileprivate
> private
>
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the
awkward parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the
submodule name/path in parens: private(foo.bar.baz) or
moduleprivate(foo.bar). Putting an identifier in the parens is much more
natural than putting keywords in parens.
>
> What do you all think?
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
I'm not sure my wording will be perfect here, but I will try: I still
believe that private is implied in "module" and "file" and the problem is
in the name of the plain "private" keyword.
You may say private is obvious, but when you have moduleprivate and
fileprivate, the natural question I ask is "What remaining kind of private
is there?" so private's obviousness is muddied for me when next to
moduleprivate and fileprivate.
I will say I would prefer these keywords to the proposed parameter
keywords. I just think:
file -> implies file only
module -> implies module only
where adding private to them only adds noise (I.e. fileprivate and
moduleprivate)
Yep good point Ross. Should have double checked that.(I think it is because kids in school kept saying intermural instead of intramural You would think the latin I took would have broken me of that. :-).
I think all of the proposals below are clear and I like any of them except 3, too long. The parenthesized ones are if we want consistency between the middle two scopes.
So, proposal one (and 1b), more technical sounding
public
internal (or intramodule)
intrafile
private
Proposal two infile (and 2b). Shortest, eye pleasing, non technical sounding
public
internal (or moduleprivate)
fileprivate
private
proposal four: (and 4b):kind of needs the 4b form, to show pattern (I think)
private
internal (modulewide)
filewide
private
proposal five (and 5b) short eye pleasing.
private
internal (moduleonly)
fileonly
private
···
On Mar 31, 2016, at 2:10 AM, Ross O'Brien <narrativium+swift@gmail.com> wrote:
> 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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>>:
>>
>>> On Mar 23, 2016, at 10:13 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
>>> How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:
>>>
>>> public
>>> moduleprivate
>>> fileprivate
>>> private
>>>
>>> The advantages, as I see them are:
>>> 1) We keep public and private meaning the “right” and “obvious” things.
>>> 2) The declmodifiers “read” correctly.
>>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.
>>> 4) The unusual ones would be “googable”.
>>> 5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). Putting an identifier in the parens is much more natural than putting keywords in parens.
>>
>> 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 <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/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 <swift-evolution@swift.org> 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 <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 <clattner@apple.com> wrote:
> How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:
>
> public
> moduleprivate
> fileprivate
> private
>
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). Putting an identifier in the parens is much more natural than putting keywords in parens.
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”.
- 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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>>:
>>
>>> On Mar 23, 2016, at 10:13 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
>>> How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:
>>>
>>> public
>>> moduleprivate
>>> fileprivate
>>> private
>>>
>>> The advantages, as I see them are:
>>> 1) We keep public and private meaning the “right” and “obvious” things.
>>> 2) The declmodifiers “read” correctly.
>>> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.
>>> 4) The unusual ones would be “googable”.
>>> 5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). Putting an identifier in the parens is much more natural than putting keywords in parens.
>>
>> 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 <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
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 <narrativium+swift@gmail.com> 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 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
"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 <sean@fifthace.com> 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 <narrativium+swift@gmail.com> > 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 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
>
Just to double check: do I need to do anything with the proposal? It sounds
like it was decided, and Doug will update the proposal, but I 'd like to
make sure that there is nothing to be done on my end.
···
On Fri, Apr 1, 2016 at 5:07 PM Ilya Belenkiy <ilya.belenkiy@gmail.com> wrote:
Great! Glad that we have a decision.
On Fri, Apr 1, 2016 at 4:34 PM Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
On Mar 30, 2016, at 9:22 PM, Chris Lattner <clattner@apple.com> 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
Hi Everyone,
Thank you for all of the input. I know that this was a highly
contentious topic, that it is impossible to make everyone happy. Getting
the different inputs and perspectives has been very very useful.
The core team met to discuss this, and settled on the list above:
public/internal/fileprivate/private. This preserves the benefit of the
“fileprivate” concept that we have today in Swift, while aligning the
“private” keyword with common expectations of people coming to Swift. This
also makes “private" the "safe default” for cases where you don’t think
about which one you want to use, and this schema will cause minimal churn
for existing Swift code.
Thank you again for all of the input and discussion!
The state of the art is:
public private(set) var foo = 0
If I'm reading and understanding this correctly, you propose a generally postfix solution like this:
public var foo = 0 { // marks default getter and setter public however...
private set // marks default setter private
}
Unless there's a specific getter or setter implementation, I'm not fond of the
postfix declarations. In my opinion `private set` is modifying `public`, not `var foo = 0`
I recognize that in a type rather than a global variable, the modification
override could not be adjacent. Another comparison. Current art:
public struct bar {
private(set) var gar = 0
}
vs (what I think is) your suggestion:
public struct bar {
var gar = 0 {
private set
}
}
And again, moving the access control modification to the end just doesn't look
right to me or seem to enhance readability. :(
-- E
···
On Mar 15, 2016, at 3:09 PM, Shawn Erickson <shawnce@gmail.com> wrote:
The last sentence was meant to be:
Private and public have well defined meaning, we should keep the same semantics.
Still, this is an edge case. Maybe we can separate it into another proposal.
I think any change in semantics should absolutely be a separate proposal. I support scope-based access semantics. My opinion about other access semantics would depend on the details of a specific proposal, but I think there is a very high hurdle to clear for introducing any other access semantics.
···
On Mar 24, 2016, at 10:52 AM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:
On Thu, Mar 24, 2016 at 11:42 AM Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is why I'd like private to mean exactly that (no nested class should get access). Then the meaning is clear: it's as private as it can be :-)
Private and public have well defined meaning. We
On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I agree that 'private' still feels too subjective on its own. It's intuitively 'not public'; it's not intuitively the access term for 'declaration only'.
I'm not opposed to fileprivate and moduleprivate, if we like those terms. I'd just prefer a corresponding scopeprivate or declarationprivate.
On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> How about we continue this trend, and follow other existing Swift keywords that merge two lowercase words (associatedtype, typealias, etc), and use:
>
> public
> moduleprivate
> fileprivate
> private
>
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the submodule name/path in parens: private(foo.bar.baz) or moduleprivate(foo.bar). Putting an identifier in the parens is much more natural than putting keywords in parens.
>
> What do you all think?
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
I'm not sure my wording will be perfect here, but I will try: I still believe that private is implied in "module" and "file" and the problem is in the name of the plain "private" keyword.
You may say private is obvious, but when you have moduleprivate and fileprivate, the natural question I ask is "What remaining kind of private is there?" so private's obviousness is muddied for me when next to moduleprivate and fileprivate.
I will say I would prefer these keywords to the proposed parameter keywords. I just think:
file -> implies file only
module -> implies module only
where adding private to them only adds noise (I.e. fileprivate and moduleprivate)
I'm going to say that I remain unhappy with these new names. I don't believe that these won't get used, and I don't want them to feel awkward, discouraged, or penalized when they do. The standard library, for example, has in its style guide that all access control should be explicit, which is a reasonable style to enforce. I also have a small concern that they won't be easy to talk about: "this method is private" "wait, file-private or module-private?" "neither, just private-private".
I realize these are all vague concerns, and I don't have something more concrete—or a better alternative. "modulescoped" and "filescoped" would be very literally accurate but (a) would force people to learn what "scoped" means unnecessarily, and (b) aren't less awkward.
I agree with the concerns that just saying "file var foo" makes it sound like there's one copy of the variable shared in the entire file, even when applied to an instance property. I think there's a lot of value is making the access control terms adjectives.
I honestly still think "public, internal, private, local" is a better taxonomy.. It's true that "internal" and "private" aren't automatically ordered relative to each other (and maybe not even "local"), but they're all adjectives (unlike "module" and "file"), and they're not awkward to read or to use in conversation. But both the core team and the list disagree, mainly because (a) it aligns 'private' more closely with other languages, and (b) if you're not thinking about it, more restrictive is better than less. (Both of which I agree are good ideas.)
Jordan
···
On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
I think it does. `module` could mean many things related to how Swift creates and consumes modules.
`moduleprivate` combines something about access levels (public/private) and scope (module), is easy to
Google, offers few "wrong" interpretations. By using a longer keyword, it is less flexible in meaning and
more fixed in purpose.
Sure, but is that worth 7 to 9 extra characters at every single use site for something that's actually pretty common? Is it worth the muddled mess of an all-lowercase keyword with no obvious break, or the attention-grabbing of a capital letter or an underscore?
`module` and `file` are not going to be obscure corners of the language. Most people will probably learn about them at the same time they learn about `public` and `private`.
(Actually, if `module` continues to be the default, you probably won't see it *that* often. You *will* see `file`, but that's the one that can't be as easily confused with a declaration.)
Obviousness for new users is great, but you can take it too far. We call the type `Int32`, not `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and if we did, it's not clear the longer name would really be more obvious, because it would be such a pain to read.
`moduleprivate` is the default value. I doubt it will get used much if at all. I don't think `fileprivate` will get used much either
but in such cases, I think those seven extra letters are essential and documenting.
The two remaining public and private access levels are simple and intuitively obvious.
I have types where I declare their members (some public, some private) and use extensions to provide the API implementations of protocols.
These implementations use data that is not public to the type. A file-based access level is the only one that works for me.
This is actually the common case for me.
···
Sent from my iPhone
On Mar 25, 2016, at 10:11 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> 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.
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
···
On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> 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 have many situations where related, and usually, nested types should have
access to implementation details of each other but I want to avoid any
other types having access to these details. The simplest example that I
have are value types that wrap one or two values. 'Unrelated' types
shouldn't have access to these `rawValue`s at all.
TJ
···
On Fri, Mar 25, 2016 at 12:11 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:
> On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> 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.
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.
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.
···
Le 25 mars 2016 à 12:57, Tino Heth via swift-evolution <swift-evolution@swift.org> a écrit :
afaics this is the third time someone mentions that "file-private" is uncommon — so I think it's time someone dissents:
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.
Kevin Lundberg
kevin@klundberg.com
···
On Mar 25, 2016, at 1:11 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> 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.
I use "file private" extensively for keys. We have a set of models that are loaded from a server into core data. We use a common method to load the values in, and we define the keys as a file private "keys" tuple (originally a struct with private static constants, but the tuple was simpler). This allows us to reuse the word keys throughout the module, which is short, clear, and doesn't pollute the rest of the module with key identifiers where they are not necessary.
I'm sure there are other ways to do this, but I've come to quite enjoy the file private system we have.
~James
···
Sent from my iPad
On Mar 25, 2016, at 10:11 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> 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.