Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
We are always willing to consider new input, but any source breaking change has to provide overwhelming rationale for it being worth the cost to the community.
-Chris
On Oct 6, 2016, at 11:39 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Do language ships ever sail?
New POV’s should always be welcome.
Just spit it out…
Rien.
On 07 Oct 2016, at 08:39, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
What in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was very much in favour of a bracketed system like:
private(scope) Current private (I think, it doesn't appear to be equivalent to protected in other languages anyway so I wouldn't call it type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current public
I favour this because it groups all restrictive access levels under private (since they're all some form of private) with an optional modifier that's explicit about what it's for. Also, it would have scope to move things like final into a modifier too, so you might declare a method as public(final), or public(open) if that's implemented later and so-on. Just seems like a generally more flexible setup that also reduces the number of keywords required.
Some may feel it's noisy, but personally I don't see it as a problem as it always comes before the func/var/let keyword, generics and function name, so it's not like it's near anything where the (minor) noise reduces readability.
But yeah, having used the new fileprivate for a little while I just don't like it; it may partly come down to the fact that I use fileprivate a lot more than I use regular private. If we were to adopt the above scheme I would recommend that private(file) be the default for use of the plain private keyword, unless we gain the ability to specify private(type) (i.e- protected in most other languages), as private(scope) seems like it's the less common, at least in my experience.
On 7 Oct 2016, at 07:39, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
This discussion is getting longer than I thought… guess it's because we can't spend our energy for proposals that introduce new features ;-)
I had some "hope" that SE-0025 would be dismissed when one of the deadlines passed without an implementation, and I was thinking about proposing to drop it — but the feature has been finished before I started writing.
Personally, I don't have problems with "new private", but it is a whole access level that's actually not needed for regular coding:
Considering the importance of playgrounds, it's desirable to be be able to teach about information hiding, which doesn't work with fileprivate — but real applications normally consist of several source files, and this use case is still my focus.
In this setup, the benefit of two access levels whose only difference can be neutralized by a very tiny reorganization of code is just theoretical.
With Swift 3, the number of access levels nearly doubled, but even with an impressive number of five options, there are still many intends that can't be expressed, so we traded a limited (but simple) system for a slightly more complex one that still lacks power.
What itches me most in this aspect is the strong preference for small, additive changes, which discourages a holistic take on big topics like this.
- Tino
+1
I would also rather have:
private(scope)
private(file)
private(module)
etc…
— A
On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was very much in favour of a bracketed system like:
private(scope) Current private (I think, it doesn't appear to be equivalent to protected in other languages anyway so I wouldn't call it type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current publicI favour this because it groups all restrictive access levels under private (since they're all some form of private) with an optional modifier that's explicit about what it's for. Also, it would have scope to move things like final into a modifier too, so you might declare a method as public(final), or public(open) if that's implemented later and so-on. Just seems like a generally more flexible setup that also reduces the number of keywords required.
Some may feel it's noisy, but personally I don't see it as a problem as it always comes before the func/var/let keyword, generics and function name, so it's not like it's near anything where the (minor) noise reduces readability.
But yeah, having used the new fileprivate for a little while I just don't like it; it may partly come down to the fact that I use fileprivate a lot more than I use regular private. If we were to adopt the above scheme I would recommend that private(file) be the default for use of the plain private keyword, unless we gain the ability to specify private(type) (i.e- protected in most other languages), as private(scope) seems like it's the less common, at least in my experience.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I agree that the keywords could be improved, but private(file) access
should not be what 'private' means by itself. If I put just 'private' in
front of something I really mean it should be private to this scope, the
most private. I also think the more common use-case would be private(scope)
over private(file), you might find if you refactor a bit that a lot of your
fileprivate can become private or instead - it's possible that fileprivate
is encouraging you to put things into one file when they should be in
multiple files with a better defined 'internal' API.
I like the *concept* that 'private' is the most private and then it can be
relaxed by modifiers (file) (module) (perhaps-other-stuff), but I'm not
convinced that 'private' is really an appropriate word for something that
is accessible anywhere within a module. Though I agree that 'internal'
doesn't really mean much to someone learning the language, and suffers the
exact same problem (internal to what?) whereas private(module) does express
that a bit better.
On Fri, 7 Oct 2016 at 09:26 Haravikk via swift-evolution < swift-evolution@swift.org> wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:
Hello community,
From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
Access Level* is the only one I’m having second thoughts about. Before
launching a discussion around it, I’m curious to know if it's worth
discussing it or if the “ship has sailed”. As the plan is to allow future
versions of Swift to break source-compatibility in certain rare scenarios,
perhaps we have a chance to reconsider certain proposals?Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was
very much in favour of a bracketed system like:private(scope) Current private (I think, it doesn't appear to be
equivalent to protected in other languages anyway so I wouldn't call it
type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current publicI favour this because it groups all restrictive access levels under
private (since they're all some form of private) with an optional modifier
that's explicit about what it's for. Also, it would have scope to move
things like final into a modifier too, so you might declare a method as
public(final), or public(open) if that's implemented later and so-on. Just
seems like a generally more flexible setup that also reduces the number of
keywords required.Some may feel it's noisy, but personally I don't see it as a problem as it
always comes before the func/var/let keyword, generics and function name,
so it's not like it's near anything where the (minor) noise reduces
readability.But yeah, having used the new fileprivate for a little while I just don't
like it; it may partly come down to the fact that I use fileprivate a lot
more than I use regular private. If we were to adopt the above scheme I
would recommend that private(file) be the default for use of the plain
private keyword, unless we gain the ability to specify private(type) (i.e-
protected in most other languages), as private(scope) seems like it's the
less common, at least in my experience.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Hello community,
From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
Access Level* is the only one I’m having second thoughts about. Before
launching a discussion around it, I’m curious to know if it's worth
discussing it or if the “ship has sailed”. As the plan is to allow future
versions of Swift to break source-compatibility in certain rare
scenarios, perhaps we have a chance to reconsider certain proposals?Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was
very much in favour of a bracketed system like:
FWIW, I fully agree with you and I do believe your suggestion just much better than current status quo. It is much clearer what private(module) means than 'internal' and private(scope) than just 'private', private(file) is 1000% better than fileprivate ;-). Currently IMO names are not consistent : if we have 'fileprivate', then we need 'scopeprivate' and 'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )
IMO
On 07.10.2016 11:24, Haravikk via swift-evolution wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
private(scope)Current private (I think, it doesn't appear to be equivalent
to protected in other languages anyway so I wouldn't call it type).
private(file)Current fileprivate
private(module)Current internal/default when omitted
publicCurrent publicI favour this because it groups all restrictive access levels under private
(since they're all some form of private) with an optional modifier that's
explicit about what it's for. Also, it would have scope to move things like
final into a modifier too, so you might declare a method as public(final),
or public(open) if that's implemented later and so-on. Just seems like a
generally more flexible setup that also reduces the number of keywords
required.Some may feel it's noisy, but personally I don't see it as a problem as it
always comes before the func/var/let keyword, generics and function name,
so it's not like it's near anything where the (minor) noise reduces
readability.But yeah, having used the new fileprivate for a little while I just don't
like it; it may partly come down to the fact that I use fileprivate a lot
more than I use regular private. If we were to adopt the above scheme I
would recommend that private(file) be the default for use of the plain
private keyword, unless we gain the ability to specify private(type) (i.e-
protected in most other languages), as private(scope) seems like it's the
less common, at least in my experience._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Yeah I'm a bit undecided on that point myself; like I say I'd really prefer something like private(type) to be the default for my own use-case, but not only do we not have that it probably wouldn't suit everyone anyway, I think it's just more that my habit is to implement by extension within the same file. With that in mind maybe scope is the better default for it as you say.
I'm not sure what the OP really wanted to raise on the subject, but if there's interest for this style of access modifier and it's in-scope for Swift 4 then I could do a proposal for it as a specific request.
On 7 Oct 2016, at 12:11, Jay Abbott <jay@abbott.me.uk> wrote:
I agree that the keywords could be improved, but private(file) access should not be what 'private' means by itself. If I put just 'private' in front of something I really mean it should be private to this scope, the most private. I also think the more common use-case would be private(scope) over private(file), you might find if you refactor a bit that a lot of your fileprivate can become private or instead - it's possible that fileprivate is encouraging you to put things into one file when they should be in multiple files with a better defined 'internal' API.
I like the *concept* that 'private' is the most private and then it can be relaxed by modifiers (file) (module) (perhaps-other-stuff), but I'm not convinced that 'private' is really an appropriate word for something that is accessible anywhere within a module. Though I agree that 'internal' doesn't really mean much to someone learning the language, and suffers the exact same problem (internal to what?) whereas private(module) does express that a bit better.
FWIW, I fully agree with you and I do believe your suggestion just much
...
'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )
+1
I would also much prefer
private(scope)
private(file)
private(module)
etc...
While no topic is formally off the table, to revisit a topic requires fresh
insight. `private(file)` was suggested at the time and rejected in favor of
`fileprivate`, and we really don't need another rehash of how much each
person likes one or the other.
On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution < swift-evolution@swift.org> wrote:
+1
I would also rather have:
private(scope)
private(file)
private(module)
etc…— A
On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution < > swift-evolution@swift.org> wrote:
Hello community,
From all the proposals which has gone into Swift 3, *[SE-0025] Scoped
Access Level* is the only one I’m having second thoughts about. Before
launching a discussion around it, I’m curious to know if it's worth
discussing it or if the “ship has sailed”. As the plan is to allow future
versions of Swift to break source-compatibility in certain rare scenarios,
perhaps we have a chance to reconsider certain proposals?Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was
very much in favour of a bracketed system like:private(scope) Current private (I think, it doesn't appear to be
equivalent to protected in other languages anyway so I wouldn't call it
type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current publicI favour this because it groups all restrictive access levels under
private (since they're all some form of private) with an optional modifier
that's explicit about what it's for. Also, it would have scope to move
things like final into a modifier too, so you might declare a method as
public(final), or public(open) if that's implemented later and so-on. Just
seems like a generally more flexible setup that also reduces the number of
keywords required.Some may feel it's noisy, but personally I don't see it as a problem as it
always comes before the func/var/let keyword, generics and function name,
so it's not like it's near anything where the (minor) noise reduces
readability.But yeah, having used the new fileprivate for a little while I just don't
like it; it may partly come down to the fact that I use fileprivate a lot
more than I use regular private. If we were to adopt the above scheme I
would recommend that private(file) be the default for use of the plain
private keyword, unless we gain the ability to specify private(type) (i.e-
protected in most other languages), as private(scope) seems like it's the
less common, at least in my experience.
_______________________________________________
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
Even if these access modifier names seem to make sense, I don’t really see the need of the reconsideration here.
private(scope) == private
private(file) == fileprivate
private(module) == internal
Lhs does add more noise, and if I had to tell, fileprivate actually reads well and better than private(file).
Which problem isn’t solved here yet? I might be blind and don’t read between the lines.
--
Adrian Zubarev
Sent with Airmail
Am 7. Oktober 2016 um 16:03:07, Adriano Ferreira via swift-evolution (swift-evolution@swift.org) schrieb:
+1
I would also rather have:
private(scope)
private(file)
private(module)
I actually prefer "fileprivate" to the alternatives, but imo using the word
"private" is a bad choice for this, since it's basically a relative term.
If we're going with parens "visibility(file)" makes more sense to me.
On Fri, Oct 7, 2016 at 5:00 AM, Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote:
> FWIW, I fully agree with you and I do believe your suggestion just much
> ...
> 'moduleprivate'.. but these are just ugly(just like fileprivate ;-) )+1
I would also much prefer
private(scope)
private(file)
private(module)
etc...
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I'd prefer to use public(file), etc over private. You are determining which code has access over which code doesn't. I don't think its that confusing to say the default is just public(module)
Sent with my Thumbs
On Oct 7, 2016, at 9:21 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
While no topic is formally off the table, to revisit a topic requires fresh insight. `private(file)` was suggested at the time and rejected in favor of `fileprivate`, and we really don't need another rehash of how much each person likes one or the other.
On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution <swift-evolution@swift.org> wrote:
+1I would also rather have:
private(scope)
private(file)
private(module)
etc…— A
On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was very much in favour of a bracketed system like:
private(scope) Current private (I think, it doesn't appear to be equivalent to protected in other languages anyway so I wouldn't call it type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current publicI favour this because it groups all restrictive access levels under private (since they're all some form of private) with an optional modifier that's explicit about what it's for. Also, it would have scope to move things like final into a modifier too, so you might declare a method as public(final), or public(open) if that's implemented later and so-on. Just seems like a generally more flexible setup that also reduces the number of keywords required.
Some may feel it's noisy, but personally I don't see it as a problem as it always comes before the func/var/let keyword, generics and function name, so it's not like it's near anything where the (minor) noise reduces readability.
But yeah, having used the new fileprivate for a little while I just don't like it; it may partly come down to the fact that I use fileprivate a lot more than I use regular private. If we were to adopt the above scheme I would recommend that private(file) be the default for use of the plain private keyword, unless we gain the ability to specify private(type) (i.e- protected in most other languages), as private(scope) seems like it's the less common, at least in my experience.
_______________________________________________
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
I’m +1 on the following:
current
new
private
private
fileprivate
private(file)
internal
private(module)
public
public
open
open
The only thing that keeps bothering me is private(set) and how it will harmonize with this proposed scheme.
Regards,
Adrian Kashivskyy
Wiadomość napisana przez David Waite via swift-evolution <swift-evolution@swift.org> w dniu 07.10.2016, o godz. 17:54:
I'd prefer to use public(file), etc over private. You are determining which code has access over which code doesn't. I don't think its that confusing to say the default is just public(module)
Sent with my Thumbs
On Oct 7, 2016, at 9:21 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
While no topic is formally off the table, to revisit a topic requires fresh insight. `private(file)` was suggested at the time and rejected in favor of `fileprivate`, and we really don't need another rehash of how much each person likes one or the other.
On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1I would also rather have:
private(scope)
private(file)
private(module)
etc…— A
On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was very much in favour of a bracketed system like:
private(scope) Current private (I think, it doesn't appear to be equivalent to protected in other languages anyway so I wouldn't call it type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current publicI favour this because it groups all restrictive access levels under private (since they're all some form of private) with an optional modifier that's explicit about what it's for. Also, it would have scope to move things like final into a modifier too, so you might declare a method as public(final), or public(open) if that's implemented later and so-on. Just seems like a generally more flexible setup that also reduces the number of keywords required.
Some may feel it's noisy, but personally I don't see it as a problem as it always comes before the func/var/let keyword, generics and function name, so it's not like it's near anything where the (minor) noise reduces readability.
But yeah, having used the new fileprivate for a little while I just don't like it; it may partly come down to the fact that I use fileprivate a lot more than I use regular private. If we were to adopt the above scheme I would recommend that private(file) be the default for use of the plain private keyword, unless we gain the ability to specify private(type) (i.e- protected in most other languages), as private(scope) seems like it's the less common, at least in my experience.
_______________________________________________
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I started the topic, but I also believe like you that the fileprivate vs private(file) discussion has already been thoroughly discussed and nothing new has been brought up. That’s not what I want to discuss.
I instead want to share my experience using private and fileprivate since release. Here are my thoughts:
We should start with the premise that the proposal has added a substantial amount of complexity:
It has added an extra modifier and access level to learn.
It has complicated the access level rules with Inner types as mentioned in the Complications with private types section of the proposal.
I have seen many people (twitter, work, slack) be confused about the difference between private and fileprivate at the global level. The answer is none, which shows that both modifiers are not very orthogonal.
Since release, I saw people prefer one over the other, as a matter of style. They tend to always use fileprivate or always using private. In the latter case, functions and properties get clumped in the same class scope instead of be written through multiple extensions.
I have the impression that the motivations for the proposal are much less real in practice:
The first motivation stated is: "It is not clear whether the implementation details are meant to be completely hidden or can be shared with some related code without the danger of misusing the APIs marked as private.” I’ve found that to be fairly rare in practice because the implementation details only used to leak inside the same file, which greatly reduces the dangers.
The second motivation stated is: "It forces a one class per file structure, which is very limiting." First of all, this is partly false. I think it forces putting classes which share implementation details in the same file, which I don’t think is necessarily a bad thing.
To summarise, it seems that the confusion the proposal brought over semantics and style are not worth the limited benefits that it brought. I’d be tempted to backtrack the proposal and re-introduce private as a file scoped access-level and deprecate fileprivate.
Thoughts?
David.
On 7 Oct 2016, at 17:21, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
While no topic is formally off the table, to revisit a topic requires fresh insight. `private(file)` was suggested at the time and rejected in favor of `fileprivate`, and we really don't need another rehash of how much each person likes one or the other.
On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1I would also rather have:
private(scope)
private(file)
private(module)
etc…— A
On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was very much in favour of a bracketed system like:
private(scope) Current private (I think, it doesn't appear to be equivalent to protected in other languages anyway so I wouldn't call it type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current publicI favour this because it groups all restrictive access levels under private (since they're all some form of private) with an optional modifier that's explicit about what it's for. Also, it would have scope to move things like final into a modifier too, so you might declare a method as public(final), or public(open) if that's implemented later and so-on. Just seems like a generally more flexible setup that also reduces the number of keywords required.
Some may feel it's noisy, but personally I don't see it as a problem as it always comes before the func/var/let keyword, generics and function name, so it's not like it's near anything where the (minor) noise reduces readability.
But yeah, having used the new fileprivate for a little while I just don't like it; it may partly come down to the fact that I use fileprivate a lot more than I use regular private. If we were to adopt the above scheme I would recommend that private(file) be the default for use of the plain private keyword, unless we gain the ability to specify private(type) (i.e- protected in most other languages), as private(scope) seems like it's the less common, at least in my experience.
_______________________________________________
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
To summarise, it seems that the confusion the proposal brought over semantics and style are not worth the limited benefits that it brought. I’d be tempted to backtrack the proposal and re-introduce private as a file scoped access-level and deprecate fileprivate.
This is my personal preference, to back out the fileprivate/private change before Swift becomes any more crystallized. That being said, I think the bar for 'novel insight' has to be very high for something like this to be a wise idea, lest we end up endlessly revisiting every idea that wasn't unanimously popular. Do we have any evidence the new access control system is proving a hindrance to developers, or specific information we didn't have during the original discussion?
Austin
On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
Thoughts?
David.On 7 Oct 2016, at 17:21, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
While no topic is formally off the table, to revisit a topic requires fresh insight. `private(file)` was suggested at the time and rejected in favor of `fileprivate`, and we really don't need another rehash of how much each person likes one or the other.
On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1I would also rather have:
private(scope)
private(file)
private(module)
etc…— A
On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 7 Oct 2016, at 07:39, David Hart via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello community,
From all the proposals which has gone into Swift 3, [SE-0025] Scoped Access Level is the only one I’m having second thoughts about. Before launching a discussion around it, I’m curious to know if it's worth discussing it or if the “ship has sailed”. As the plan is to allow future versions of Swift to break source-compatibility in certain rare scenarios, perhaps we have a chance to reconsider certain proposals?
Regards,
David.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolutionWhat in particular don't you like about it?
Personally I still don't like the use of fileprivate as the keyword, I was very much in favour of a bracketed system like:
private(scope) Current private (I think, it doesn't appear to be equivalent to protected in other languages anyway so I wouldn't call it type).
private(file) Current fileprivate
private(module) Current internal/default when omitted
public Current publicI favour this because it groups all restrictive access levels under private (since they're all some form of private) with an optional modifier that's explicit about what it's for. Also, it would have scope to move things like final into a modifier too, so you might declare a method as public(final), or public(open) if that's implemented later and so-on. Just seems like a generally more flexible setup that also reduces the number of keywords required.
Some may feel it's noisy, but personally I don't see it as a problem as it always comes before the func/var/let keyword, generics and function name, so it's not like it's near anything where the (minor) noise reduces readability.
But yeah, having used the new fileprivate for a little while I just don't like it; it may partly come down to the fact that I use fileprivate a lot more than I use regular private. If we were to adopt the above scheme I would recommend that private(file) be the default for use of the plain private keyword, unless we gain the ability to specify private(type) (i.e- protected in most other languages), as private(scope) seems like it's the less common, at least in my experience.
_______________________________________________
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I agree. The minor benefit that fileprivate brings is not worth the cognitive overhead it introduces. We should just admit it was a mistake and back it out. We can avoid source-breaking changes by making fileprivate a synonym for private and provide fixits/warnings for a release to give people a chance to move off it.
Russ
On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
I started the topic, but I also believe like you that the fileprivate vs private(file) discussion has already been thoroughly discussed and nothing new has been brought up. That’s not what I want to discuss.
I instead want to share my experience using private and fileprivate since release. Here are my thoughts:
We should start with the premise that the proposal has added a substantial amount of complexity:
It has added an extra modifier and access level to learn.
It has complicated the access level rules with Inner types as mentioned in the Complications with private types section of the proposal.
I have seen many people (twitter, work, slack) be confused about the difference between private and fileprivate at the global level. The answer is none, which shows that both modifiers are not very orthogonal.
Since release, I saw people prefer one over the other, as a matter of style. They tend to always use fileprivate or always using private. In the latter case, functions and properties get clumped in the same class scope instead of be written through multiple extensions.
I have the impression that the motivations for the proposal are much less real in practice:
The first motivation stated is: "It is not clear whether the implementation details are meant to be completely hidden or can be shared with some related code without the danger of misusing the APIs marked as private.” I’ve found that to be fairly rare in practice because the implementation details only used to leak inside the same file, which greatly reduces the dangers.
The second motivation stated is: "It forces a one class per file structure, which is very limiting." First of all, this is partly false. I think it forces putting classes which share implementation details in the same file, which I don’t think is necessarily a bad thing.To summarise, it seems that the confusion the proposal brought over semantics and style are not worth the limited benefits that it brought. I’d be tempted to backtrack the proposal and re-introduce private as a file scoped access-level and deprecate fileprivate.
Thoughts?
David.
I third this sentiment. fileprivate is a nice idea and very clearly has
its uses (which is why the proposal got traction in the first place),
but when combined with the other access levels, the language feature as
a whole feels arbitrary. In practical use, files that I felt were nicely
encapsulated and hiding implementation details are now a scattered mix
of access levels, adding cognitive load and making the code look
unorganized for having the gall to use extensions to split up
functionality.
Sincerely,
Zachary Waldowski
zach@waldowski.me
On Fri, Oct 7, 2016, at 01:55 PM, Russ Bishop via swift-evolution wrote:
On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution <swift- >> evolution@swift.org> wrote:
I started the topic, but I also believe like you that the
*fileprivate* vs *private(file)* discussion has already been
thoroughly discussed and nothing new has been brought up. That’s not
what I want to discuss.I instead want to share my experience using *private* and
*fileprivate* since release. Here are my thoughts:1. We should start with the premise that the proposal has added a
substantial amount of complexity:
1. It has added an extra modifier and access level to learn.
2. It has complicated the access level rules with Inner types as
mentioned in the *Complications with private types* section of
the proposal.
3. I have seen many people (twitter, work, slack) be confused
about the difference between *private* and *fileprivate* at the
global level. The answer is none, which shows that both
modifiers are not very orthogonal.
4. Since release, I saw people prefer one over the other, as a
matter of style. They tend to always use *fileprivate* or
always using *private*. In the latter case, functions and
properties get clumped in the same class scope instead of be
written through multiple extensions.
2. I have the impression that the motivations for the proposal are
much less real in practice:
1. The first motivation stated is: *"It is not clear whether the
implementation details are meant to be completely hidden or can
be shared with some related code without the danger of misusing
the APIs marked as private.”* I’ve found that to be fairly rare
in practice because the implementation details only used to
leak inside the same file, which greatly reduces the dangers.
2. The second motivation stated is: *"It forces a one class per
file structure, which is very limiting." *First of all, this is
partly false. I think it forces putting classes which share
implementation details in the same file, which I don’t think is
necessarily a bad thing.To summarise, it seems that the confusion the proposal brought over
semantics and style are not worth the limited benefits that it
brought. I’d be tempted to backtrack the proposal and re-introduce
private as a file scoped access-level and deprecate fileprivate.Thoughts?
David.I agree. The minor benefit that fileprivate brings is not worth the
cognitive overhead it introduces. We should just admit it was a
mistake and back it out. We can avoid source-breaking changes by
making fileprivate a synonym for private and provide fixits/warnings
for a release to give people a chance to move off it.Russ
_________________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I strongly agree with this sentiment. SE-0025 was very heavily discussed, and while many people were not satisfied with the solution we went with (including me!), it was what the core team and community converged on. I don't expect us to change access control again until and unless we decide to change the model in some way, and even then I think we'll want to go through extra effort to maintain compatibility with Swift 3. As has been mentioned repeatedly, the bar for source-breaking changes is much higher than it was in the first few months of swift-evolution.
I actually consider it very lucky that most of our changes so far have been fairly non-controversial. Everybody has a different idea of what would make Swift a better language, and all of us well-meaning. But when those ideas conflict, some group is going to end up unhappy. I'm actually very glad that (a) we haven't had too many of these cases, and (b) even when we have, people have been able to accept it and move on to contributing to the next issue.
Jordan
On Oct 7, 2016, at 15:15, William Sumner via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I third this sentiment. fileprivate is a nice idea and very clearly has its uses (which is why the proposal got traction in the first place), but when combined with the other access levels, the language feature as a whole feels arbitrary. In practical use, files that I felt were nicely encapsulated and hiding implementation details are now a scattered mix of access levels, adding cognitive load and making the code look unorganized for having the gall to use extensions to split up functionality.
Sincerely,
Zachary Waldowski
zach@waldowski.me <mailto:zach@waldowski.me>Beyond the textual change of using a different modifier name, I don’t see how the encapsulation and organization of code could be affected. Really, there’s not much point in rehashing prior discussion of SE-0025 unless there’s a previously unconsidered angle.