Swift evolution proposal: introduce typeprivate access control level


(Gonçalo Alvarez Peixoto) #1

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I
would love to run it by all of you so I get everyone's feedback and enrich
it.

This proposal consists of introducing a new *typeprivate *access control
level which allows for members to be accessed in all extensions of a given
*type,* whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/master/
proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo


(Robert Widmann) #2

The proposal, as it stands, does nothing to indicate how this is much different from internal - all examples given would trivially be solved by internal members. I don’t think we need finer-grained access control to address this, I think we need extensions, at least in the same file as their parent declarations, to be able to define variables.

···

On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution <swift-evolution@swift.org> wrote:

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I would love to run it by all of you so I get everyone's feedback and enrich it.

This proposal consists of introducing a new typeprivate access control level which allows for members to be accessed in all extensions of a given type, whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Gonçalo Alvarez Peixoto) #3

Robert,

Thanks for your feedback.

However, I tend to disagree with you.

*"The proposal, as it stands, does nothing to indicate how this is much
different from internal - all examples given would trivially be solved by
internal members."*
This proposal aims at covering all of the cases in which you *do not want* to
expose your properties *internally. *For instance, you might want to access
a member of a view controller from an extension of this view controller on
another file, but not make it accessible from other members in the
module (which is what *internal *does).

Best,
Gonçalo

···

2016-11-29 15:53 GMT+00:00 Robert Widmann <devteam.codafi@gmail.com>:

The proposal, as it stands, does nothing to indicate how this is much
different from internal - all examples given would trivially be solved by
internal members. I don’t think we need finer-grained access control to
address this, I think we need extensions, at least in the same file as
their parent declarations, to be able to define variables.

On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution < > swift-evolution@swift.org> wrote:

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I
would love to run it by all of you so I get everyone's feedback and enrich
it.

This proposal consists of introducing a new *typeprivate *access control
level which allows for members to be accessed in all extensions of a given
*type,* whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/
master/proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #4

As you pointed out, Swift already has quite a lot access levels…
Comparing the usefulness, "typeprivate" would clearly win over (Swift 3) "private" for me — but it adds a "new dimension" to the game, and I guess this will be a dealbreaker:
Should it be possible to access typeprivate data from another module in an extension or subclass?

- Tino


("João David (Personal)") #5

Definetely the access control topic is highly contestable in the Swift scene but nevertheless I really strive for more flexibility in terms of how can I decouple and decompose my code arch among several source files.
As an example, I reckon that the current approach of attributing properties with fileprivate is somehow encouraging developers to workaround patterns like "protected" accessors into padding files with endless classes hierarchies and that’s one of the main reasons why I’m agains’t this fileprivate access modifier in the first place.
To sum up, I really strive for code with great encapsulation and this proposal is for sure marching in that direction.

If we can add extensibility to classes without break fundamental encapsulation rules while doing it in a organised way, without stuffing file sources with the whole class spectrum, we have a winner in my opinion.

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I
would love to run it by all of you so I get everyone's feedback and enrich
it.

This proposal consists of introducing a new *typeprivate *access control
level which allows for members to be accessed in all extensions of a given
*type,* whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/master/
proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo

João David
iOS Software Architect
LinkedIn <http://pt.linkedin.com/in/joaotdavid> | +351 933631927 | Skype: joaotdavid

Please visit the iSOPARC <http://ciafel.fade.up.pt/isoparc> and iSOFIT <http://ciafel.fade.up.pt/isofit> for iPad application website.


(Brandon Knope) #6

Is anyone starting to think the current access control model will become more burdensome over time?

People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language.

For example, fileprivate and private encourage stuffing a lot of code into one file just to use that access control level. If you want to break this into more manageable chunks you have to make it internal or move it into a new module which is very complicated to do in Xcode (I.e requiring a new target like a framework).

This keeps leading me back to having submodules or creating modules on demand. I think that would open up this system to great complexity.

Want to keep something private to a specific class but private to anything outside of it? Make it internal to the same "submodule".

I think we could keep tacking on things to access control, but I don't think it is really solving everyone's needs. I think a more flexible system would allow people to adapt it to their needs instead of structuring everything around a rigid system that forces you to do it swift's way.

···

On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution <swift-evolution@swift.org> wrote:

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I would love to run it by all of you so I get everyone's feedback and enrich it.

This proposal consists of introducing a new typeprivate access control level which allows for members to be accessed in all extensions of a given type, whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Robert Widmann) #7

Is that a particularly common case? I haven’t written code that needs access patterns like this and it strikes me as strange that anything you’re willing to expose to extensions scattered throughout your codebase you’d also prefer not to export throughout a module that you have complete control over. Sure, it might be “cleaner” to scope your variables to the implementation, but past a certain point it just seems to encourage extreme decomposition and scattering of a single class or structure when you should be separating your implementation into multiple classes and structures.

···

On Nov 29, 2016, at 11:07 AM, Gonçalo Alvarez Peixoto <goncalo.alvarezpeixoto@gmail.com> wrote:

Robert,

Thanks for your feedback.

However, I tend to disagree with you.

"The proposal, as it stands, does nothing to indicate how this is much different from internal - all examples given would trivially be solved by internal members."
This proposal aims at covering all of the cases in which you do not want to expose your properties internally. For instance, you might want to access a member of a view controller from an extension of this view controller on another file, but not make it accessible from other members in the module (which is what internal does).

Best,
Gonçalo

2016-11-29 15:53 GMT+00:00 Robert Widmann <devteam.codafi@gmail.com <mailto:devteam.codafi@gmail.com>>:
The proposal, as it stands, does nothing to indicate how this is much different from internal - all examples given would trivially be solved by internal members. I don’t think we need finer-grained access control to address this, I think we need extensions, at least in the same file as their parent declarations, to be able to define variables.

On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I would love to run it by all of you so I get everyone's feedback and enrich it.

This proposal consists of introducing a new typeprivate access control level which allows for members to be accessed in all extensions of a given type, whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Gonçalo Alvarez Peixoto) #8

Hey, Robert!

Thanks for your feedback.

I do believe that it is a common practice, and a good one as well, to have
your code broken down into separate extensions, either for improving code
readability by reducing the size of the implementation file, as well as
creating context for feature development.

Also, I do agree that one should have separate classes, structs, enums or
whatever better fits the purpose, handle code regarding a single
responsibility. However, should this responsibility remain within the scope
of the type we're implementing it on, it's best to have the code split into
separate extensions on separate files (so to avoid large and hard to
inspect files), and have these extensions access members which, would *no
longer* *be visible* to the whole module. I do believe, having these
members marked as *internal* creates the conditions for one to *scatter*
and *decompose *a type since it opens the door for type in the module to
lay hands on it's members. *Typeprivate* would prevent these members to be
accessed from everywhere in the module, while enabling them to be reached
from everywhere within their type.

Also, I believe that having the scope of a member limited by file scope
does does fall short in fitting a language design purpose, as file is a
compiler related construct which could, in turn, be replaced somewhere in
time, thus leaving the “fileprivate” access member orphaned.

Best,
Gonçalo

···

2016-11-29 16:13 GMT+00:00 Robert Widmann <devteam.codafi@gmail.com>:

Is that a particularly common case? I haven’t written code that needs
access patterns like this and it strikes me as strange that anything you’re
willing to expose to extensions scattered throughout your codebase you’d
also prefer not to export throughout a module that you have complete
control over. Sure, it might be “cleaner” to scope your variables to the
implementation, but past a certain point it just seems to encourage extreme
decomposition and scattering of a single class or structure when you should
be separating your implementation into multiple classes and structures.

On Nov 29, 2016, at 11:07 AM, Gonçalo Alvarez Peixoto < > goncalo.alvarezpeixoto@gmail.com> wrote:

Robert,

Thanks for your feedback.

However, I tend to disagree with you.

*"The proposal, as it stands, does nothing to indicate how this is much
different from internal - all examples given would trivially be solved by
internal members."*
This proposal aims at covering all of the cases in which you *do not want* to
expose your properties *internally. *For instance, you might want to
access a member of a view controller from an extension of this view
controller on another file, but not make it accessible from other members
in the module (which is what *internal *does).

Best,
Gonçalo

2016-11-29 15:53 GMT+00:00 Robert Widmann <devteam.codafi@gmail.com>:

The proposal, as it stands, does nothing to indicate how this is much
different from internal - all examples given would trivially be solved by
internal members. I don’t think we need finer-grained access control to
address this, I think we need extensions, at least in the same file as
their parent declarations, to be able to define variables.

On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution >> <swift-evolution@swift.org> wrote:

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I
would love to run it by all of you so I get everyone's feedback and enrich
it.

This proposal consists of introducing a new *typeprivate *access control
level which allows for members to be accessed in all extensions of a given
*type,* whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/maste
r/proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Gonçalo Alvarez Peixoto) #9

Hello, Tino!

Thanks for your feedback.

I do suggest an alternative, in which *typeprivate *replaces file private,
since I believe that having the scope of a member limited by file scope
does does fall short in fitting a language design purpose, as file is a
compiler related construct which could, in turn, be replaced somewhere in
time, thus leaving the “fileprivate” access member orphaned.

I should not be accessed from another module, since that's what *internal*
is for. *typeprivate *would still create a private context.

Best,
Gonçalo

···

2016-11-29 16:16 GMT+00:00 Tino Heth <2th@gmx.de>:

As you pointed out, Swift already has quite a lot access levels…
Comparing the usefulness, "typeprivate" would clearly win over (Swift 3)
"private" for me — but it adds a "new dimension" to the game, and I guess
this will be a dealbreaker:
Should it be possible to access typeprivate data from another module in an
extension or subclass?

- Tino


(Jean-Daniel) #10

Definetely the access control topic is highly contestable in the Swift scene but nevertheless I really strive for more flexibility in terms of how can I decouple and decompose my code arch among several source files.
As an example, I reckon that the current approach of attributing properties with fileprivate is somehow encouraging developers to workaround patterns like "protected" accessors into padding files with endless classes hierarchies and that’s one of the main reasons why I’m agains’t this fileprivate access modifier in the first place.
To sum up, I really strive for code with great encapsulation and this proposal is for sure marching in that direction.

If we can add extensibility to classes without break fundamental encapsulation rules while doing it in a organised way, without stuffing file sources with the whole class spectrum, we have a winner in my opinion.

If you add a typeprivate accessor, it means you expose your internal details to all extensions and so breaks encapsulation.
It also means that anybody who want to access your private var will just have to write an extension to expose it.

···

Le 30 nov. 2016 à 16:00, João David via swift-evolution <swift-evolution@swift.org> a écrit :

> Hello, everyone!
>
> I would like to introduce a new proposal to swift evolution, but first I
> would love to run it by all of you so I get everyone's feedback and enrich
> it.
>
> This proposal consists of introducing a new *typeprivate *access control
> level which allows for members to be accessed in all extensions of a given
> *type,* whether lying within or in another file.
>
> You'll find the proposal draft in:
> https://github.com/goncaloalvarez/swift-evolution/blob/master/
> proposals/NNNN-introduce-typeprivate-access-control-level.md
>
> Thanks in advance for taking the time to evaluate the proposal.
>
> Best regards,
> Gonçalo
>
>
>

João David
iOS Software Architect
LinkedIn <http://pt.linkedin.com/in/joaotdavid> | +351 933631927 | Skype: joaotdavid

Please visit the iSOPARC <http://ciafel.fade.up.pt/isoparc> and iSOFIT <http://ciafel.fade.up.pt/isofit> for iPad application website.

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


(Brandon Knope) #11

This keeps leading me back to having submodules or creating modules on demand. I think that would open up this system to great complexity.

I meant "flexibility"...not complexity. Freudian slip? :joy:

Brandon


(Rien) #12

And the funny thing is, we don’t actually _need_ access control levels.

The only purpose of access control is to enhance security/reliability by imposing restrictions on other programmers (API users).

It seems to me that in almost all discussions the arguments are mostly backwards: i.e. formulated from the perspective of the API users. Maybe because just about all programmers are API users of the OS-API? Anyway…

What I would like to see is a complete overhaul of the access control and rewrite it entirely from the perspective of the API provider.
I.e. give a more fine grained control to the API writer in the sense that he can specify exactly which other piece of code has access. I consider it dangerous by default to open up a scope just because another class needs occasional access. (i.e. give -for example- module access just because there is 1 other class in the module that needs that access. Inadvertently opening up access to all other classes in that module.)

An access control list could do just that. Perhaps something like:

access(type, MyFriendClass(get))

The above would provide access to the entire type (but not any children) and read-only from MyFriendClass.

A quick -off the cuff- list of access levels:

local: access only to local scope (default)
type: Only the type in which it is defined (no children)
child: The type and its children
<type-name>: Access is granted to the type named
file: Access is limited to this file only
<file-name>: Access is granted to the named file
module: Access is granted to the entire module
<module-name>: Access is granted to the module with the given name
public: Access is granted to everybody

Further access specification could be made possible through the use of the dot-notation:

<type-name>.<function-name>
<file-name>.<class-name | function-name>
<module-name>.<class-name>.<function-name>

Read/write control through a parameter passing notation:

<type-name>.<function-name>([[get],][set])

Examples:

access(type) var count: Int // entire type can read/write
access(type(get), type.incrementer) var count: Int // Entire type can read, only the incrementer function has read/write
access(module, FriendType, public(get)) var count: Int // Entire module can read/write, FriendType can read/write, others can only read

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl

···

On 01 Dec 2016, at 21:38, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Is anyone starting to think the current access control model will become more burdensome over time?

People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language.

For example, fileprivate and private encourage stuffing a lot of code into one file just to use that access control level. If you want to break this into more manageable chunks you have to make it internal or move it into a new module which is very complicated to do in Xcode (I.e requiring a new target like a framework).

This keeps leading me back to having submodules or creating modules on demand. I think that would open up this system to great complexity.

Want to keep something private to a specific class but private to anything outside of it? Make it internal to the same "submodule".

I think we could keep tacking on things to access control, but I don't think it is really solving everyone's needs. I think a more flexible system would allow people to adapt it to their needs instead of structuring everything around a rigid system that forces you to do it swift's way.

On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution <swift-evolution@swift.org> wrote:

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I would love to run it by all of you so I get everyone's feedback and enrich it.

This proposal consists of introducing a new typeprivate access control level which allows for members to be accessed in all extensions of a given type, whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo
_______________________________________________
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


("João David (Personal)") #13

Still better than exposing to any subclass implementation or direct external access IMHO.

···

Sent from my iPhone. Erroneous words are a feature, not a typo.

On 1 Dec 2016, at 07:40, Jean-Daniel <dev@xenonium.com> wrote:

If you add a typeprivate accessor, it means you expose your internal details to all extensions and so breaks encapsulation.


(Tino) #14

It also means that anybody who want to access your private var will just have to write an extension to expose it.

imho this is wrong thinking:
Access control is no tool to offer real "protection" — it can't stop someone who wants to break a system.
Especially in the world of open source, it is merely an advice from the author not to do certain things.


(Gonçalo Alvarez Peixoto) #15

@Brandon

*Is anyone starting to think the current access control model will become
more burdensome over time?*

*People will want to add and subtract to it for years to come...which tells
me it's not very flexible. I'm beginning to feel like it is an old style
model trying to fit into a modern language. *

.Most definitely. We've mentioned earlier in this thread the usage of file
private feels somehow we're basing swift design on compiler related
constructs.

*For example, fileprivate and private encourage stuffing a lot of code into
one file just to use that access control level. If you want to break this
into more manageable chunks you have to make it internal or move it into a
new module which is very complicated to do in Xcode (I.e requiring a new
target like a framework). *

*.*Agreed. As stated before, this might lead into some kind of pattern
where types are chunked into the same file for the sakes of member access
convenience. I strongly believe we should aim at promoting code clarity and
readability while enhancing single responsibility principle's good
practices.

*This keeps leading me back to having submodules or creating modules on
demand. I think that would open up this system to great complexity.*

*Want to keep something private to a specific class but private to anything
outside of it? Make it internal to the same "submodule". *

*I think we could keep tacking on things to access control, but I don't
think it is really solving everyone's needs. I think a more flexible system
would allow people to adapt it to their needs instead of structuring
everything around a rigid system that forces you to do it swift's way. *

Don't you feel that would defeat the purpose of access control levels?
Correct if I'm wrong, but I don't think there's much to gain from trying to
dodge the need for private (whether scope private, fileprivate or
eventually typeprivate) members no matter how modularised your code is.
Also, I believe it an unworthy effort, as I think we could run the risk of
creating problems further in the chain of access control levels? I just
think we'd be pushing the problem further up the hill.

Best,
Gonçalo

···

2016-12-01 20:40 GMT+00:00 Brandon Knope <bknope@me.com>:

> This keeps leading me back to having submodules or creating modules on
demand. I think that would open up this system to great complexity.

I meant "flexibility"...not complexity. Freudian slip? :joy:

Brandon


(Tino) #16

And the funny thing is, we don’t actually _need_ access control levels.

That is true (but actually, there isn't much that is really needed :wink:
[Months ago, I've been thinking of proposing a system that is backed by private/public key cryptography — just to make fun of some overstated plans :wink: ]

My very own opinion is that Swift doesn't need a more sophisticated model — it just should have a good ratio of complexity and power.
By accepting the change of meaning for "private" and adding a fourth level, imho we gave up on simplicity in favour for theoretical benefits, and mixed concerns (ability to call vs. ability to override) with "open".
So, the current system is quite complex, yet it lacks power…
An ACL-like scheme would even be a little bit more complex, but add a significant amount of expressiveness, so I'd prefer it over the status quo.
The decision between ACL and "private, internal, public" would be much harder, though — but afaics, the majority aims for one of the extremes, so we'll most likely have to live with a compromise here.

It seems to me that in almost all discussions the arguments are mostly backwards: i.e. formulated from the perspective of the API users.

Can you elaborate on this and point out examples?


(Adrian Zubarev) #17

There is some really deep talk going on here again. But instead of introducing even more access modifiers we probably should fix some of the existing ones.

Don’t get me wrong, I understand what the authors of the proposal are trying to introduce to the language, but even if such a proposal would be accepted, there will be people who would beg for typepublic access modifier.

I tried to get some attention from the community after we introduced open to the language, because we literally created an inconsistent area for protocols.

Now we have open vs public classes, where open means you can subclass your type from module A in module B, and public prevents this.

What’s up with protocols?

(protocol) conforming == abstract subtyping (classes)

Fixing this area would prevent the API user from using protocols which are public but not meant to be used there (at least not to be conformed to), because there was some implementation artifact that prevented the framework author from hiding such a protocol.

Something like “hands off from _SomeName protocols” could be enforced by the language rather than some convention, which some API users might not even read.

That said, some hacks like this should be prevented:

struct A : _ExpressibleByBuiltinIntegerLiteral {
    init(_builtinIntegerLiteral value: _MaxBuiltinIntegerType) {}
}

struct B : ExpressibleByIntegerLiteral {
    init(integerLiteral value: A) {
        print(type(of: value))
    }
}

let b: B = 42 // prints "A"
We introduced an exclusive access modifier for classes which is really odd to be honest. We should extend it to protocols as well.

In Module A:

open protocol X - can be conformed to from module B
public protocol Y - cannot be confronted to from module B, but instead might be used as an interface

···

--
Adrian Zubarev
Sent with Airmail

Am 2. Dezember 2016 um 09:56:49, Rien via swift-evolution (swift-evolution@swift.org) schrieb:

And the funny thing is, we don’t actually _need_ access control levels.

The only purpose of access control is to enhance security/reliability by imposing restrictions on other programmers (API users).

It seems to me that in almost all discussions the arguments are mostly backwards: i.e. formulated from the perspective of the API users. Maybe because just about all programmers are API users of the OS-API? Anyway…

What I would like to see is a complete overhaul of the access control and rewrite it entirely from the perspective of the API provider.
I.e. give a more fine grained control to the API writer in the sense that he can specify exactly which other piece of code has access. I consider it dangerous by default to open up a scope just because another class needs occasional access. (i.e. give -for example- module access just because there is 1 other class in the module that needs that access. Inadvertently opening up access to all other classes in that module.)

An access control list could do just that. Perhaps something like:

access(type, MyFriendClass(get))

The above would provide access to the entire type (but not any children) and read-only from MyFriendClass.

A quick -off the cuff- list of access levels:

local: access only to local scope (default)
type: Only the type in which it is defined (no children)
child: The type and its children
<type-name>: Access is granted to the type named
file: Access is limited to this file only
<file-name>: Access is granted to the named file
module: Access is granted to the entire module
<module-name>: Access is granted to the module with the given name
public: Access is granted to everybody

Further access specification could be made possible through the use of the dot-notation:

<type-name>.<function-name>
<file-name>.<class-name | function-name>
<module-name>.<class-name>.<function-name>

Read/write control through a parameter passing notation:

<type-name>.<function-name>([[get],][set])

Examples:

access(type) var count: Int // entire type can read/write
access(type(get), type.incrementer) var count: Int // Entire type can read, only the incrementer function has read/write
access(module, FriendType, public(get)) var count: Int // Entire module can read/write, FriendType can read/write, others can only read

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl

On 01 Dec 2016, at 21:38, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

Is anyone starting to think the current access control model will become more burdensome over time?

People will want to add and subtract to it for years to come...which tells me it's not very flexible. I'm beginning to feel like it is an old style model trying to fit into a modern language.

For example, fileprivate and private encourage stuffing a lot of code into one file just to use that access control level. If you want to break this into more manageable chunks you have to make it internal or move it into a new module which is very complicated to do in Xcode (I.e requiring a new target like a framework).

This keeps leading me back to having submodules or creating modules on demand. I think that would open up this system to great complexity.

Want to keep something private to a specific class but private to anything outside of it? Make it internal to the same "submodule".

I think we could keep tacking on things to access control, but I don't think it is really solving everyone's needs. I think a more flexible system would allow people to adapt it to their needs instead of structuring everything around a rigid system that forces you to do it swift's way.

On Nov 29, 2016, at 10:24 AM, Gonçalo Alvarez Peixoto via swift-evolution <swift-evolution@swift.org> wrote:

Hello, everyone!

I would like to introduce a new proposal to swift evolution, but first I would love to run it by all of you so I get everyone's feedback and enrich it.

This proposal consists of introducing a new typeprivate access control level which allows for members to be accessed in all extensions of a given type, whether lying within or in another file.

You'll find the proposal draft in:
https://github.com/goncaloalvarez/swift-evolution/blob/master/proposals/NNNN-introduce-typeprivate-access-control-level.md

Thanks in advance for taking the time to evaluate the proposal.

Best regards,
Gonçalo
_______________________________________________
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


(Álvaro Monteiro) #18

I think the idea behind this proposal is quite the contrary. It is about
conveying the right message through the use of an expressive access control
that addresses common use cases and leaves behind fileprivate which IMHO is
a C inherited way of thinking.

Let me try to be clear:

- Private would work the same way as it does now: it would not be
accessible through an extension.
- Typeprivate would be accessible through an extension inside the module.
- Typeprivate would allow to abandon the odd fileprivate. Access level
would be constrained to swift constructs (structs, classes and extensions)
and not to a compiler artifact (file).
- Typeprivate would allow to address a very common use case: separate
concerns of a swift struct/class through extensions and at the same time
allow accessing private properties within this class/struct. At the moment
you would have to have everything in the same file (and leverage
fileprivate) or use internal and let it be accessible across the module.
One good argument in favor of internal in these use cases would be that a
given module should only be worried about what it exposes to consumers
(public) and internally it's only a concern to the developers ("producers")
of the module. I disagree with this because communication is one of the
core tenets of swift and stating a property is internal just because is
declared in another file is bizarre, unswift, error prone and it surely
does not convey the right message the developer wants.

···

On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

It also means that anybody who want to access your private var will just
have to write an extension to expose it.

imho this is wrong thinking:
Access control is no tool to offer real "protection" — it can't stop
someone who wants to break a system.
Especially in the world of open source, it is merely an advice from the
author not to do certain things.

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


(Daniel Leping) #19

How about making things more organized and move to syntax like this:

private(scope) decl

Where scope is optional and defaults to full private. Can take "file" and
"type" values. I.e:

private (file) var i = 1
private func a()
private (type) func b()

This way we can have a very fine grained access levels and maintain a
better structure. Who knows maybe in Swift 5 there will be need for more.

···

On Thu, 1 Dec 2016 at 12:08 Álvaro Monteiro via swift-evolution < swift-evolution@swift.org> wrote:

I think the idea behind this proposal is quite the contrary. It is about
conveying the right message through the use of an expressive access control
that addresses common use cases and leaves behind fileprivate which IMHO is
a C inherited way of thinking.

Let me try to be clear:

- Private would work the same way as it does now: it would not be
accessible through an extension.
- Typeprivate would be accessible through an extension inside the module.
- Typeprivate would allow to abandon the odd fileprivate. Access level
would be constrained to swift constructs (structs, classes and extensions)
and not to a compiler artifact (file).
- Typeprivate would allow to address a very common use case: separate
concerns of a swift struct/class through extensions and at the same time
allow accessing private properties within this class/struct. At the moment
you would have to have everything in the same file (and leverage
fileprivate) or use internal and let it be accessible across the module.
One good argument in favor of internal in these use cases would be that a
given module should only be worried about what it exposes to consumers
(public) and internally it's only a concern to the developers ("producers")
of the module. I disagree with this because communication is one of the
core tenets of swift and stating a property is internal just because is
declared in another file is bizarre, unswift, error prone and it surely
does not convey the right message the developer wants.

On Thu, Dec 1, 2016 at 9:31 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote:

It also means that anybody who want to access your private var will just
have to write an extension to expose it.

imho this is wrong thinking:
Access control is no tool to offer real "protection" — it can't stop
someone who wants to break a system.
Especially in the world of open source, it is merely an advice from the
author not to do certain things.

_______________________________________________
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


("João David (Personal)") #20

Exactly. Totally agree Tino.

···

Sent from my iPhone. Erroneous words are a feature, not a typo.

On 1 Dec 2016, at 09:31, Tino Heth <2th@gmx.de> wrote:

It also means that anybody who want to access your private var will just have to write an extension to expose it.

imho this is wrong thinking:
Access control is no tool to offer real "protection" — it can't stop someone who wants to break a system.
Especially in the world of open source, it is merely an advice from the author not to do certain things.