[swift-evolution] access control

[Ilya Belenkiy]

>> Yes, but with an API based access control, 
> 
> I don't know what that term means, sorry.

I had to come up with this term to distinguish it from a file based access control. In API based access control, visibility of anything is tied to the declaration instead of the file it is in. It’s the model that C++ and C# ( and I am sure many others) use. In file based access control, visibility of anything is tied to the file it is in and has little to do with the class API itself. It’s the model that Swift currently follows.

>> anyone modifying / extending the class can instantly see the author’s
>> intent from the API declaration, 
> 
> I don't see how that's different from what we have in Swift.  Private
> APIs are the ones you don't want anyone to touch because they can break
> your invariants.

In Swift, any additional code in the same source file can use the APIs declared private and break your invariants. The semantic meaning of private is not “use only inside the class” but “use only inside this file”. It is currently impossible to express “use only inside the class” semantics.

> Seeing the keyword “private” isn't enough for you in Swift, but it is in
> C++?  Why?

Because in Swift, private means “use only inside this file” and not “use only inside this class / scope”. In C++ private means “use only inside this class”. Moreover, C++ puts a special emphasis on this — variables are private inside the class unless the code specifically says otherwise.

>  Defining one type per file is usually a good practice anyway.

This really depends on the context. There is value in keeping similar concepts / implementations in the same file. If one class and one extension per file become a requirement, then private will have the same semantics as in C++. It will also become very inconvenient to write code because even a small extension with 1 method that can fit on one line will require a separate file.

> Without prohibiting class extensions from being made in the same file
> where the class is defined—a capability we want to keep available to
> class authors—that will always be the case.


It doesn’t have to be. My proposal (still a pull request) provides a way to explicitly declare a function or a property to be private to the scope where it is defined. So extensions and subclasses declared in the same file cannot access it and break the invariant. If it’s applied to both class definitions and extensions, it’s very consistent and provides an explicit declaration of intent that can (and should) be enforced by the compiler.

> Therefore, you have the
> same scenario as in C++: anyone who modifies the file where a class is
> defined might be violating its invariants.  It's just that in C++ the
> violator has to write code between a particular set of braces.  When
> reviewing diffs it's very common not to have enough context to see those
> braces anyway.

This is a crucial distinction. That particular set of braces defines a scope which acts as a black box and hides the implementation details. Anything outside the scope cannot damage the internal state, and the compiler *enforces* it. In Swift, the compiler only enforces that the API is not visible from another file because the language has no way to express “this should be visible only in the scope to hide implementation details”. The only exception to that are functions inside other functions and local variables — right now this is the only way to completely hide implementation details, but it’s very limited.

My main 2 points are that it’s impossible to express the intent of a truly local access level to hide implementation details, and because of that, the compiler cannot enforce this intent.

> When
> reviewing diffs it's very common not to have enough context to see those
> braces anyway.

This depends on how thoroughly the code is reviewed. But the main point there is that when you find out, you know that whoever worked around a private API did so knowing that he was introducing a hack. Because Swift has no way of expressing “this is private to the class, not just file it’s in”, someone may not know and make a mistake, and the compiler cannot catch it. My proposal makes the intent expressible in the language and enforceable by the compiler.

> Not at all in the same way.  In C++, you can't add methods to a class
> outside the file where it's declared unless there's some really horrible
> preprocessor stuff going on, and even then the class author would have
> had to explicitly left that door open for you.

True, but my proposal deals with extensions the same way it does with class definitions — it provides a way to hide implementation details in a scope (whether it be a class definition or an extension scope) and make them invisible to everything else including extensions or other extensions or anything else in the same file. It provides a way to express the intent in the language and enforce it by the compiler.

> On Jan 23, 2016, at 5:43 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Sat Jan 23 2016, Ilya Belenkiy <ilya.belenkiy-AT-gmail.com> wrote:
> 
>>> Anyone who can "add more code to the same file" can just as easily modify/extend the class.  
>> 
>> Yes, but with an API based access control, 
> 
> I don't know what that term means, sorry.
> 
>> anyone modifying / extending the class can instantly see the author’s
>> intent from the API declaration, 
> 
> I don't see how that's different from what we have in Swift.  Private
> APIs are the ones you don't want anyone to touch because they can break
> your invariants.
> 
>> and the compiler can prevent *accidental* misuse. Deliberate misuse
>> cannot be stopped no matter what access control is in place (as long
>> as the coder can modify the code in the module). But at least with an
>> API based access control, a deliberate misuse is very easy to spot
>> when debugging / reviewing the code. With a file based access control,
>> the only way to tell if an API is really private or can be safely used
>> anywhere in the same file is to read the comments / source code. 
> 
> Seeing the keyword “private” isn't enough for you in Swift, but it is in
> C++?  Why?
> 
>> And it’s much easier to miss in maintenance, debugging, or code
>> reviews. The only way to make it obvious in the current model is to
>> adopt a convention like _ in front of methods.
> 
> The only reason we're doing that in the standard library is that we're
> currently forced to make some implementation details formally public,
> and we can't use “private” because <reasons>.  If it weren't for these
> limitations, we'd be very happy with “private.”  Defining one type per
> file is usually a good practice anyway.
> 
>>> There's nothing about extending a class that ought to raise a red
>>> flag in Swift, because it's perfectly legit to do so and use only
>>> the class' public APIs.
>> 
>> Unless the programmer extends a class in the same file. Then he can
>> call anything marked private, and it’s impossible to tell without
>> reading the code whether it violates the class invariants. 
> 
> Without prohibiting class extensions from being made in the same file
> where the class is defined—a capability we want to keep available to
> class authors—that will always be the case.  Therefore, you have the
> same scenario as in C++: anyone who modifies the file where a class is
> defined might be violating its invariants.  It's just that in C++ the
> violator has to write code between a particular set of braces.  When
> reviewing diffs it's very common not to have enough context to see those
> braces anyway.
> 
>> There is no way to express this in Swift today. My proposal for local
>> / scoped access control would solve this.
>> 
>>> we didn't do file-level access control because it was easier; we
>>> did it because we thought it was a better model for Swift, where
>>> types are liberally open for extension.
>> 
>> That’s what I assumed until I saw someone say it in this list when
>> someone else raised a similar concern. Types in C++ and C# are also
>> liberally open for extension, 
> 
> Not at all in the same way.  In C++, you can't add methods to a class
> outside the file where it's declared unless there's some really horrible
> preprocessor stuff going on, and even then the class author would have
> had to explicitly left that door open for you.
> 
> 
> -- 
> -Dave