I hope there is only a small minority of programmers who actually need such kind of "safety" — that sounds more like fighting colleagues working in the same codebase than productive work.
Still, even when it is futile to say "you can't call that method here", there is merit in being able to express that you probably should not use some function you could access.
For example, take set of routines which handle updates in UIKit: There are methods which you should never call, but because you need the ability to override, it is impossible to make them internal.
1 Like
I can see your point about (the lack of) security. The natural conclusion of that reasoning is that as we realistically can only set user's permissions on a file basis (e.g. in a git repository, etc) - file shall be the unit of security. Got you.
(Still, an ability to add variables to your types scattered across different files would be beneficial (for some of us). Currently I can scatter extension methods across files, but variables need to go to the single "main" file - that's not scaleable. I admit this is a totally different issue, so I want to dismiss this particular angle from this thread, it belongs elsewhere.)
If protected were visible only to a type's extensions, subclasses, and conformances within the module (i.e. like internal) then would this alleviate the security issues while allowing classes to be broken up over files?
If this happens frequently (does it?) it deserves a special treatment in the language (similar to how the opposite case is handled - via final)
There's no practical difference between that and using internal. Any one of those same module extensions can expose any protected member publicly.
Come on, there is an obvious practical difference, internal makes the member accessible directly from any other type, protected makes it only available from extensions of the original type.
There's definitely a difference (duh), but I'm not sure if such difference is practical. I'd rather see folder-level access control than a type-based one. Though I'm not sure how folder-level access would work with the current compilation model.
4 Likes
I can reasonably easy bypass my microwave protection and run it with its door open. Does it mean microwaves should not have door protection? :)
Just don't treat private/protected access levels to be bulletproof. By means of another analogy they are more like a locked door made of glass - won't stop a motivated person but will stop 99% opportunity thieves. wide open door - public access. closed unlocked door - protected access. closed locked door - private access.
1 Like
What unmotivated person would need these kinds of protections in the first place? I don't believe they exist. I'll go further, they categorically do not exist. If they're writing code internal to your module, then they're writing code internal to your module. Either you trust them to extend your types correctly, or you don't. If you don't trust them to have full access to a type outside of an extension then you also should not trust them inside of an extension. This whole idea is a solution in search of a problem.
1 Like
A typical use case is a private method that's only made internal to be callable from different files to keep individual file sizes manageable. This private method is not intended to be used other than in certain other methods. This method is not meant to be used even my me, the author, and naturally a few months from now I will forget about it, or disregard my own past guideline and call it anyway because it is trivial. Or someone else on the team does, which is even more probable. private/internal levels would raise the bar, make it a bit more complex to misuse and help preventing a foot-gun. The doc comment would be a poor man unchecked solution to this problem. I believe the problem is real, otherwise we would not see this issue raised now and again with the frequency it appears.
3 Likes
Well, a good reason to split your codebase into modules. Once you do that, using internal will seem natural.
1 Like
The protected attribute would serve as a documentation. It would also be a marker that a source analysis tool could use to find improper re-publication of the declaration.
Code is not only written for the compiler. This is one of the design principles of Swift.
Note: this does not mean I do think it should exist.
1 Like
Swift modules are not particularly lightweight, and splitting individual types into modules would lead to very long import lists.
What Swift needs is proper name-spacing, including an access modifier that limits to the name-space.
4 Likes
The logical conclusion of your argument is that the only access modifier Swift needs is public, with anything not so marked treated as internal. Swift has obviously chosen not to go in that direction, so I think it's fair to consider further modifications.
2 Likes
To expound on @xwu’s answer, the reason access levels are designed the way they are in Swift is to enable local reasoning, i.e. the ability to understand a piece of code and make changes to it without having to understand the entire program.
When you make something private or fileprivate it means that you only ever need to look at that particular file to see where it is used. When you make something internal, you need to look at all the files in the module to see where it is used. If private members were accessible from any file, you would need to look at all the files in the module to see where they are used. So in terms of local reasoning, it would be no different from internal – you would still need to look at all files.
Remember also that any function func foo(bar: Bar) in Swift can be rewritten as extension Bar { func foo() }. So to say that something "can only be used from within a type" is a distinction with very little practical difference.
4 Likes
For me, my desire for protected access (limited to within a module) is largely as stated by other proponents. It helps with encapsulation, logical structure, and organisation of the source code, and guards against lapses of self-discipline. It does not help with security if someone else can modify the module source code, but then nor does private. It does help with expressing the intent of a function or member variable (one intent being that it is an implementation detail of the class which could be subject to source-breaking changes).
Since it makes no practical difference to a compiled binary, I don't think it needs to be literally a language or compiler feature; it could just as well be an IDE and/or lint feature generating a warning.
2 Likes
You keep saying "all files" but that's not true in the majority of cases. In practice I'd search for "extension TypeName" or ": ClassName" + "class", and that would lead to a much smaller file set. Yes in theory it can be every file of the project (*), while in reality it would be, say, 1% of all files of the project. Besides it's not the whole file of that file set I will have to analyse, only (potentially) a small portion of the file where "extension TypeName" is. On top of that we can use "fileprivate" to really limit the scope to just one file. (the other "private" would be more like "typeprivate" (I would not nitpick and allow typeprivate usage in protocols as well)). I can also self discipline myself to only keep relevant things per file, so even if type implementation is scattered across, say, 10 files I can make so happen that they only contain the type extension(s) (one or a few per file) and nothing irrelevant. That will limit the scope of "local reasoning" area to 10 files, out of a thousand. Just because the scope spans across several files doesn't (for me) necessarily prohibit local reasoning.
(*) C++ is not different here, the class implementation methods could be scattered across all files of the project... Just because it's possible doesn't mean it would be a norm, perhaps 1 to 10 files would contain class implementation, out of, say, thousands files of a big project.
Module split is not a good option for the proponents of this change: different types within module will be able accessing internal ("typeprivate" in my parlance) details of other types of that module. Unless of course you are talking about "a module per type"... but that's waaay too heavy. Don't know about teams / projects you've worked on, in my experience modules are only used for external third party components, or, possibly, a standalone component of a separate team in the same company.
We're trying too hard to shoehorn the old model verbatim without much effort to make it feel more at home in the language (a.k.a, we’re fileprivate-ing this). If the problem is that fileprivate is too small and internal is too large, there’re still some other designs we can explore instead of doubling down on this protected design.
I especially don’t want the good old days of designing all my class hierarchies to soothe the access control divine being. I’d rather turn some properties internal rather than turning global function into type members. The latter workaround works pretty poorly for API design.
4 Likes
Very well summarised btw.
We'd like to hear ideas about those other designs. Whatever fixes the problem works for me (aside the fact that a good proportion of us believes there is no problem to solve 
The introduction of a new, say, "typeprivate" doesn't mean you have to necessarily use it or otherwise "micromanage" types' access rights, it's an opt-in.