access control

anandabits · January 26, 2016, 2:14pm

It seems to be the opposite, these example work in a playground:

let public: Int = 123

error: keyword 'public' cannot be used as an identifier

However:

struct Test {
private(set) var set: Int
}

no errors

You are right. The access modifiers are not available as identifiers while most other decl modifiers are allowed: The Swift Programming Language: Redirect. I should have checked before mentioning what I did about decl modifiers.

I think that `module` and `file` without further context may be confusing. I also think that `class` that I had is probably confusing.

You’re probably right about `module` and `file` having potential for confusion without context. With that in mind, `internal` is probably better than `module` and is what we already have..

I don't see the additional verbosity as a problem, I think the more frequently used ones are probably fine.

I'm happy for them all to be keywords, the original proposal had some good suggestions there, I just think what I've suggested is a bit nicer.

I think that what I'm suggesting would increase safety and granularity, with only one new case you didn't have, and it would actually reduce the number of keywords.

I did cover all of your cases. Making a distinction based on the type of scope (class vs extension) doesn’t seem to be worthwhile. If you really wanted to stick with the private syntax `private(scope)` would make the most sense and would work for any kind of scope.

However I think that is verbose. I think we have a couple of reasonable options.

Ilya’s proposal and closest to current state:
* public, internal, private, local (or scoped)

Change `private` to be scope-based and come up with something new for file-level visibility:
* public, internal, ??? file level, private

My preference depends on what we could come up with for file-level visibility. If it’s better than `local` or `scoped` I would prefer that. If not, I would prefer Ilya’s proposal. In other words, we should choose the option with the best overall clarity.

-Matthew

···

On Jan 25, 2016, at 9:22 PM, Andrew Bennett <cacoyi@gmail.com> wrote:

On Tue, Jan 26, 2016 at 1:51 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

On Jan 25, 2016, at 8:37 PM, Andrew Bennett <cacoyi@gmail.com <mailto:cacoyi@gmail.com>> wrote:

I like file scoped private, it's way better than C++'s `friend`. I also often feel that it's unsafe when I've mentally scoped implementation details to a class or extension, but the implementations are in the same file.

I would support something like this:
    * `private(module)` alternatively `internal`, the default.
    * `private` alternatively `private(file)`
    * `private(class)`
    * `private(extension)`
    * `public`

I like the basic breakdown of functionality here, but why overload private with so many variations? This is more verbose than necessary. I think we can get away with being more clear and concise (access modifiers are decl modifiers, not keywords so they don’t steal identifiers, IIUC).

Why not this:

    * `public`
    * `module`, the default (currently `internal`).
    * `file` (currently `private`)
    * `private` (no current equivalent: containing scope whether class, struct, enum, extension, etc)

Perhaps this could let us deprecate/remove the keyword `internal`, I'm not sure of many circumstances when you'd actually need to write it.

I also think that `private(module)` is also more intuitively understood than `internal`.

My reasoning:

This seems to come down to:
It lowers the cognitive load if you can put related concepts in the same file.
It lowers the cognitive load if you can reduce the number of things a class needs to understand.
People like the current system, its simple and it works for them.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - The Elements of Programming Style

On Tue, Jan 26, 2016 at 12:46 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On Jan 25, 2016, at 5:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
> on Mon Jan 25 2016, Ilya Belenkiy <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>>> Why should the compiler enforce this? That’s my design decision.
>>
>> It would enforce whatever design decision you make.
>>
>>> For the same reason the compiler does not enforce where I have to
>>> put „private“ (it can make suggestions like many IDEs do and offer
>>> fix-its, like „this method can be made private as it is not used
>>> outside the class“ or „this class can be put into its own file as
>>> its private methods are not used by other components in this file“.
>>
>> But once you do put it, it enforces it, and that’s the whole point of having access control.
>>
>>> No, there is a clear difference: making the type name part of the
>>> variable name enforces no compiler checks whereas putting something
>>> into different files does.
>>
>> Similarly, putting all of the source code in the same file is
>> equivalent to no checks.
>
> The place where I'm most concerned about this is in playgrounds. If
> we're going to use them to teach programming, it should be possible to
> demonstrate encapsulation there.
>

Using playgrounds for teaching is a great example of a use case for this. Thanks for mentioning it!

I also think the fact that “surrounding scope” is actually the most frequent use of `private` members (in code I have surveyed) indicates that it is a very reasonable feature request. Allowing us to declare the actual intent aids readability and clarity.

-Matthew

> --
> -Dave
>
> _______________________________________________
> 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

anandabits · January 26, 2016, 2:22pm

This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important.

I agree. Most of the value comes from clarity of intent backed by a compiler guarantee. That is how we know the code actually follows the intent. I’m pretty sure Rob intended the compiler guarantee to be a critical part of the “message” past-Rob sends future-Rob.

···

On Jan 26, 2016, at 7:00 AM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

The reasoning is the same as having real types instead of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type related information in general

I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

_______________________________________________
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

Taras_Zakharko1 · January 26, 2016, 1:36pm

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ). See also the summary at the end of my mail. Subclass scope is a different story, because it has many practical uses, but thats a topic for another discussion.

The reasoning is the same as having real types instead of conventions for naming objects:

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

No compiler sugar will prevent people from using your internal APIs if they want to. With Objective-C this is particularly easy, due to the dynamic nature of the language. Even if Swift had the definition scope access modifier, one could get access to your private interface by reverse-engineering the memory layout of your object and accessing the state directly. The only real argument in favour of definition scope is bug prevention, and as far as I am concerned, it is a matter of opinion (I do like your point about autocompletion though). Again, as I wrote before, I am ambivalent. I don’t think that Swift will loose anything by introducing definition scope access but I also don’t think that it will gain anything.

At any rate, I can’t help but notice that we are going in circles here. I think that the decision should be made by the core Swift team, who should evaluate how well it fits with their vision.

Best,

Taras

···

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important. The reasoning is the same as having real types instead of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type related information in general

I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

_______________________________________________
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

anandabits · January 26, 2016, 2:26pm

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :)

Doc strings easily become out of sync with the code. The critical part of the “message” is that it actually aligns with the current state of the code. This is only guaranteed if it is part of the language and enforced by the compiler.

). See also the summary at the end of my mail. Subclass scope is a different story, because it has many practical uses, but thats a topic for another discussion.

The reasoning is the same as having real types instead of conventions for naming objects:

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

I’ll let Ilya respond for himself. But I agree with you. This proposal provides orders of magnitude less value. Nevertheless, it provides value that is significantly greater than the small increment in complexity that an additional access modifier adds to the language.

···

On Jan 26, 2016, at 7:36 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

No compiler sugar will prevent people from using your internal APIs if they want to. With Objective-C this is particularly easy, due to the dynamic nature of the language. Even if Swift had the definition scope access modifier, one could get access to your private interface by reverse-engineering the memory layout of your object and accessing the state directly. The only real argument in favour of definition scope is bug prevention, and as far as I am concerned, it is a matter of opinion (I do like your point about autocompletion though). Again, as I wrote before, I am ambivalent. I don’t think that Swift will loose anything by introducing definition scope access but I also don’t think that it will gain anything.

At any rate, I can’t help but notice that we are going in circles here. I think that the decision should be made by the core Swift team, who should evaluate how well it fits with their vision.

Best,

Taras

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important. The reasoning is the same as having real types instead of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type related information in general

I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

_______________________________________________
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

Ilya_Belenkiy · January 26, 2016, 2:29pm

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

Why not automate it if we can?

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ).

Would you remove all type checking and rely solely on the documentation to make function calls? If you wouldn’t, exactly the same reasoning applies to *where* a function can be called.

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

I can and I do. Data encapsulation is a cornerstone for object oriented programming for a very good reason.

No compiler sugar will prevent people from using your internal APIs if they want to.

True, but the same applies to type checking. We should have real data encapsulation for exactly the same reason.

At any rate, I can’t help but notice that we are going in circles here.

We are. I hope that my pull request with the proposal will be merged and reviewed soon. This issue has already received plenty of discussion here.

···

On Jan 26, 2016, at 8:36 AM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ). See also the summary at the end of my mail. Subclass scope is a different story, because it has many practical uses, but thats a topic for another discussion.

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
The reasoning is the same as having real types instead of conventions for naming objects:

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

No compiler sugar will prevent people from using your internal APIs if they want to. With Objective-C this is particularly easy, due to the dynamic nature of the language. Even if Swift had the definition scope access modifier, one could get access to your private interface by reverse-engineering the memory layout of your object and accessing the state directly. The only real argument in favour of definition scope is bug prevention, and as far as I am concerned, it is a matter of opinion (I do like your point about autocompletion though). Again, as I wrote before, I am ambivalent. I don’t think that Swift will loose anything by introducing definition scope access but I also don’t think that it will gain anything.

At any rate, I can’t help but notice that we are going in circles here. I think that the decision should be made by the core Swift team, who should evaluate how well it fits with their vision.

Best,

Taras

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important. The reasoning is the same as having real types instead of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type related information in general

I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

_______________________________________________
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

Ilya_Belenkiy · January 26, 2016, 4:01pm

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

I’d like to add one more thing here: the whole point of having distinct types is to be able to specify what can be done with instances of those types and to enforce it. Access control is part of that — it tells what can (and cannot) be done with an instance of a particular type. It is a small part in terms of complexity involved in both specifying and enforcing types, but it’s an important part of the solution to the real problem that the type system solves: what operations are available for an instance of a type.

···

On Jan 26, 2016, at 9:29 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> wrote:

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

Why not automate it if we can?

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ).

Would you remove all type checking and rely solely on the documentation to make function calls? If you wouldn’t, exactly the same reasoning applies to *where* a function can be called.

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

I can and I do. Data encapsulation is a cornerstone for object oriented programming for a very good reason.

No compiler sugar will prevent people from using your internal APIs if they want to.

True, but the same applies to type checking. We should have real data encapsulation for exactly the same reason.

At any rate, I can’t help but notice that we are going in circles here.

We are. I hope that my pull request with the proposal will be merged and reviewed soon. This issue has already received plenty of discussion here.

On Jan 26, 2016, at 8:36 AM, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ). See also the summary at the end of my mail. Subclass scope is a different story, because it has many practical uses, but thats a topic for another discussion.

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
The reasoning is the same as having real types instead of conventions for naming objects:

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

No compiler sugar will prevent people from using your internal APIs if they want to. With Objective-C this is particularly easy, due to the dynamic nature of the language. Even if Swift had the definition scope access modifier, one could get access to your private interface by reverse-engineering the memory layout of your object and accessing the state directly. The only real argument in favour of definition scope is bug prevention, and as far as I am concerned, it is a matter of opinion (I do like your point about autocompletion though). Again, as I wrote before, I am ambivalent. I don’t think that Swift will loose anything by introducing definition scope access but I also don’t think that it will gain anything.

At any rate, I can’t help but notice that we are going in circles here. I think that the decision should be made by the core Swift team, who should evaluate how well it fits with their vision.

Best,

Taras

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important. The reasoning is the same as having real types instead of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type related information in general

I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

_______________________________________________
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

Ilya_Belenkiy · January 27, 2016, 12:43pm

I am not sure who to ask, so I’ll ask here:

At what stage do proposals get merged into the “proposals” folder? Is there some order in which proposals get scheduled for review? My proposal was thoroughly discussed twice on this list. Is there anything else that I can do to get it scheduled for a review?

···

On Jan 26, 2016, at 9:29 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> wrote:

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

Why not automate it if we can?

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ).

Would you remove all type checking and rely solely on the documentation to make function calls? If you wouldn’t, exactly the same reasoning applies to *where* a function can be called.

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

I can and I do. Data encapsulation is a cornerstone for object oriented programming for a very good reason.

No compiler sugar will prevent people from using your internal APIs if they want to.

True, but the same applies to type checking. We should have real data encapsulation for exactly the same reason.

At any rate, I can’t help but notice that we are going in circles here.

We are. I hope that my pull request with the proposal will be merged and reviewed soon. This issue has already received plenty of discussion here.

On Jan 26, 2016, at 8:36 AM, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ). See also the summary at the end of my mail. Subclass scope is a different story, because it has many practical uses, but thats a topic for another discussion.

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
The reasoning is the same as having real types instead of conventions for naming objects:

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

No compiler sugar will prevent people from using your internal APIs if they want to. With Objective-C this is particularly easy, due to the dynamic nature of the language. Even if Swift had the definition scope access modifier, one could get access to your private interface by reverse-engineering the memory layout of your object and accessing the state directly. The only real argument in favour of definition scope is bug prevention, and as far as I am concerned, it is a matter of opinion (I do like your point about autocompletion though). Again, as I wrote before, I am ambivalent. I don’t think that Swift will loose anything by introducing definition scope access but I also don’t think that it will gain anything.

At any rate, I can’t help but notice that we are going in circles here. I think that the decision should be made by the core Swift team, who should evaluate how well it fits with their vision.

Best,

Taras

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important. The reasoning is the same as having real types instead of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type related information in general

I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

_______________________________________________
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

Douglas_Gregor · January 28, 2016, 5:05pm

I am not sure who to ask, so I’ll ask here:

At what stage do proposals get merged into the “proposals” folder? Is there some order in which proposals get scheduled for review? My proposal was thoroughly discussed twice on this list. Is there anything else that I can do to get it scheduled for a review?

One of the core team members will get it merged today. Sorry for the delay! There is a *lot* going on in swift-evolution land.

- Doug

···

On Jan 27, 2016, at 4:43 AM, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 26, 2016, at 9:29 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com <mailto:ilya.belenkiy@gmail.com>> wrote:

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

Why not automate it if we can?

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ).

Would you remove all type checking and rely solely on the documentation to make function calls? If you wouldn’t, exactly the same reasoning applies to *where* a function can be called.

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

I can and I do. Data encapsulation is a cornerstone for object oriented programming for a very good reason.

No compiler sugar will prevent people from using your internal APIs if they want to.

True, but the same applies to type checking. We should have real data encapsulation for exactly the same reason.

At any rate, I can’t help but notice that we are going in circles here.

We are. I hope that my pull request with the proposal will be merged and reviewed soon. This issue has already received plenty of discussion here.

On Jan 26, 2016, at 8:36 AM, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

This is certainly not what I wrote. What I said is that hiding the private interface becomes a practical concern on large scale, when you deal with projects or libraries. Swift already solves that issue with per-file and per-module visibility. And when editing the narrow scope (the file), one should make sure that one knows that they are doing (not unlike what you wrote yourself).

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

Oh, I quite agree with you here. But I still don’t think that declaration scope access is really necessary to achieve this (because quite honestly, the future-Taras messages are best conveyed through documentation strings :) ). See also the summary at the end of my mail. Subclass scope is a different story, because it has many practical uses, but thats a topic for another discussion.

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
The reasoning is the same as having real types instead of conventions for naming objects:

I do not believe that your example is even remotely appropriate. These problems are on a totally different scale. You can’t seriously mean the the lack of definition scope access poses challenges that are even remotely similar to those associated with the lack of type checking.

There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

No compiler sugar will prevent people from using your internal APIs if they want to. With Objective-C this is particularly easy, due to the dynamic nature of the language. Even if Swift had the definition scope access modifier, one could get access to your private interface by reverse-engineering the memory layout of your object and accessing the state directly. The only real argument in favour of definition scope is bug prevention, and as far as I am concerned, it is a matter of opinion (I do like your point about autocompletion though). Again, as I wrote before, I am ambivalent. I don’t think that Swift will loose anything by introducing definition scope access but I also don’t think that it will gain anything.

At any rate, I can’t help but notice that we are going in circles here. I think that the decision should be made by the core Swift team, who should evaluate how well it fits with their vision.

Best,

Taras

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This a great writeup on clarity of intent. I’d like to add that in principle, if clarity of intent was the only goal, it could be achieved by a universally agreed on convention, like putting _ in front of the method or property (or type) . We could put it in guidelines and rely on it in all Swift projects. The other part that it is enforced by the compiler is equally important. The reasoning is the same as having real types instead of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a useful way to convey the coder’s intent. Maintaining the code in this context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type related information in general

I am sure that everyone would be less comfortable shipping a large codebase that didn’t go through all the type checks. Exactly the same reasoning applies to “local”. If it’s just a convention that is not enforced by the compiler, we lose a very useful way to verify code correctness. In addition to that, everything that is marked as “local” (or “_” in front of the name) now shows up in code completions and adds noise and temptation to cut corners (often this would be “faster” functions that already assume certain things about the state that may generally not be true). There are plenty of discussions about Cocoa private APIs on the web where the only thing that is stopping people is whether using them will pass the app store check (and if there is a secret back door still). That specific boundary is addressed with “internal”, but the same is true at the scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Personally, I use it quite often because of the way I like to design things as groups of tightly interdependent components (friends, if you want) who are aware of each other’s inner workings. I also want to have full access to the interface of any project I work on because I trust myself to make the judgement whether I am allowed to use a particular functionality or not.

By this logic, you don't want or need private (Swift's private-to-file) either. You just want/need internal and public, because you trust your judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't remember every detail of the code I wrote today. Private-to-file is a message from past-me to future-me: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this file, but if you want to make it visible to other files, you better study it to make sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves future-Rob from bugs, and it lets past-Rob rest easy because the message is guaranteed to be delivered, and is guaranteed to be correct. No comment or policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you don't need to worry about looking for any use of this element outside this class, but if you want to make it visible to other classes, you better study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its access modifiers, but I think an access modifier for private-to-class or private-to-instance or private-to-scope would let past-Rob convey useful information to future-Rob in a lot of places where currently the information is less precise or entirely absent, and that this ability is useful enough to justify the additional language complexity.

_______________________________________________
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

Ilya_Belenkiy · January 28, 2016, 5:20pm

Great, thank you!

···

On Thu, Jan 28, 2016 at 12:05 PM Douglas Gregor <dgregor@apple.com> wrote:

On Jan 27, 2016, at 4:43 AM, Ilya Belenkiy via swift-evolution < > swift-evolution@swift.org> wrote:

I am not sure who to ask, so I’ll ask here:

At what stage do proposals get merged into the “proposals” folder? Is
there some order in which proposals get scheduled for review? My proposal
was thoroughly discussed twice on this list. Is there anything else that I
can do to get it scheduled for a review?

One of the core team members will get it merged today. Sorry for the
delay! There is a *lot* going on in swift-evolution land.

- Doug

On Jan 26, 2016, at 9:29 AM, Ilya Belenkiy <ilya.belenkiy@gmail.com> > wrote:

This is certainly not what I wrote. What I said is that hiding the private
interface becomes a practical concern on large scale, when you deal with
projects or libraries. Swift already solves that issue with per-file and
per-module visibility. And when editing the narrow scope (the file), one
should make sure that one knows that they are doing (not unlike what you
wrote yourself).

Why not automate it if we can?

Oh, I quite agree with you here. But I still don’t think that declaration
scope access is really necessary to achieve this (because quite honestly,
the future-Taras messages are best conveyed through documentation strings
:) ).

Would you remove all type checking and rely solely on the documentation to
make function calls? If you wouldn’t, exactly the same reasoning applies to
*where* a function can be called.

I do not believe that your example is even remotely appropriate. These
problems are on a totally different scale. You can’t seriously mean the the
lack of definition scope access poses challenges that are even remotely
similar to those associated with the lack of type checking.

I can and I do. Data encapsulation is a cornerstone for object oriented
programming for a very good reason.

No compiler sugar will prevent people from using your internal APIs if
they want to.

True, but the same applies to type checking. We should have real data
encapsulation for exactly the same reason.

At any rate, I can’t help but notice that we are going in circles here.

We are. I hope that my pull request with the proposal will be merged and
reviewed soon. This issue has already received plenty of discussion here.

On Jan 26, 2016, at 8:36 AM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution < > swift-evolution@swift.org> wrote:

By this logic, you don't want or need private (Swift's private-to-file)
either. You just want/need internal and public, because you trust your
judgement and you want access to everything in the project.

This is certainly not what I wrote. What I said is that hiding the private
interface becomes a practical concern on large scale, when you deal with
projects or libraries. Swift already solves that issue with per-file and
per-module visibility. And when editing the narrow scope (the file), one
should make sure that one knows that they are doing (not unlike what you
wrote yourself).

I'm not arguing that Swift needs, say, Scala's level of detail in its
access modifiers, but I think an access modifier for private-to-class or
private-to-instance or private-to-scope would let past-Rob convey useful
information to future-Rob in a lot of places where currently the
information is less precise or entirely absent, and that this ability is
useful enough to justify the additional language complexity.

Oh, I quite agree with you here. But I still don’t think that declaration
scope access is really necessary to achieve this (because quite honestly,
the future-Taras messages are best conveyed through documentation strings
:) ). See also the summary at the end of my mail. Subclass scope is a
different story, because it has many practical uses, but thats a topic for
another discussion.

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution < > swift-evolution@swift.org> wrote:

The reasoning is the same as having real types instead of conventions for
naming objects:

I do not believe that your example is even remotely appropriate. These
problems are on a totally different scale. You can’t seriously mean the the
lack of definition scope access poses challenges that are even remotely
similar to those associated with the lack of type checking.

There are plenty of discussions about Cocoa private APIs on the web where
the only thing that is stopping people is whether using them will pass the
app store check (and if there is a secret back door still). That specific
boundary is addressed with “internal”, but the same is true at the scale of
a class.

No compiler sugar will prevent people from using your internal APIs if
they want to. With Objective-C this is particularly easy, due to the
dynamic nature of the language. Even if Swift had the definition scope
access modifier, one could get access to your private interface by
reverse-engineering the memory layout of your object and accessing the
state directly. The only real argument in favour of definition scope is bug
prevention, and as far as I am concerned, it is a matter of opinion (I do
like your point about autocompletion though). Again, as I wrote before, I
am ambivalent. I don’t think that Swift will loose anything by introducing
definition scope access but I also don’t think that it will gain anything.

At any rate, I can’t help but notice that we are going in circles here. I
think that the decision should be made by the core Swift team, who should
evaluate how well it fits with their vision.

Best,

Taras

On 26 Jan 2016, at 14:00, Ilya Belenkiy via swift-evolution < > swift-evolution@swift.org> wrote:

This a great writeup on clarity of intent. I’d like to add that in
principle, if clarity of intent was the only goal, it could be achieved by
a universally agreed on convention, like putting _ in front of the method
or property (or type) . We could put it in guidelines and rely on it in all
Swift projects. The other part that it is enforced by the compiler is
equally important. The reasoning is the same as having real types instead
of conventions for naming objects:

Imagine that the Swift compiler did nothing for types — it was just a
useful way to convey the coder’s intent. Maintaining the code in this
context would become much more difficult:

1) the compiler would not help catch mistakes.
2) the tools would not provide contextual auto completions or useful type
related information in general

I am sure that everyone would be less comfortable shipping a large
codebase that didn’t go through all the type checks. Exactly the same
reasoning applies to “local”. If it’s just a convention that is not
enforced by the compiler, we lose a very useful way to verify code
correctness. In addition to that, everything that is marked as “local” (or
“_” in front of the name) now shows up in code completions and adds noise
and temptation to cut corners (often this would be “faster” functions that
already assume certain things about the state that may generally not be
true). There are plenty of discussions about Cocoa private APIs on the web
where the only thing that is stopping people is whether using them will
pass the app store check (and if there is a secret back door still). That
specific boundary is addressed with “internal”, but the same is true at the
scale of a class.

On Jan 25, 2016, at 11:22 PM, Rob Mayoff via swift-evolution < > swift-evolution@swift.org> wrote:

I agree with everything Matthew Johnson said in his response. In addition:

On Mon, Jan 25, 2016 at 5:40 PM, Taras Zakharko via swift-evolution < > swift-evolution@swift.org> wrote:

Personally, I use it quite often because of the way I like to design
things as groups of tightly interdependent components (friends, if you
want) who are aware of each other’s inner workings. I also want to have
full access to the interface of any project I work on because I trust
myself to make the judgement whether I am allowed to use a particular
functionality or not.

By this logic, you don't want or need private (Swift's private-to-file)
either. You just want/need internal and public, because you trust your
judgement and you want access to everything in the project.

I trust my judgement, but I don't trust my memory. In six months, I won't
remember every detail of the code I wrote today. Private-to-file is a
message from past-me to future-me: "Dear future-Rob, you don't need to
worry about looking for any use of this element outside this file, but if
you want to make it visible to other files, you better study it to make
sure it's safe to expose. Warmest regards, past-Rob."

This is a useful message. It helps jog future-Rob's memory, it saves
future-Rob from bugs, and it lets past-Rob rest easy because the message is
guaranteed to be delivered, and is guaranteed to be correct. No comment or
policy or convention can make that guarantee.

I want the ability to send another useful message: "Dear future-Rob, you
don't need to worry about looking for any use of this element outside this
class, but if you want to make it visible to other classes, you better
study it to make sure it's safe to expose. Very truly yours, past-Rob."

Note that moving a private class to its own file to make its privates more
private does not work. Now I have to make the formerly-private class an
internal class, so I'm not sending the first message anymore.

I'm not arguing that Swift needs, say, Scala's level of detail in its
access modifiers, but I think an access modifier for private-to-class or
private-to-instance or private-to-scope would let past-Rob convey useful
information to future-Rob in a lot of places where currently the
information is less precise or entirely absent, and that this ability is
useful enough to justify the additional language complexity.

_______________________________________________
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