[swift-evolution] access control

[Ilya Belenkiy]

> 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, anyone modifying / extending the class can instantly see the author’s intent from the API declaration, 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. 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.

> 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. 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, but they provide much better support for expressing the intent of an API and protect against accidental misuse.

> On Jan 23, 2016, at 3:45 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Sat Jan 23 2016, Ilya Belenkiy <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I hope that access control can be revisited. It is the number one
>> complaint about Swift that I hear from experienced developers. The
>> current solution came as a complete surprise to every ObjC developer
>> I've talked to. The natural expectation was that a strong access
>> control system would be part of a strong type system. I already
>> submitted a pull request with a proposal for this after a lengthy
>> discussion here, but so far it was ignored. I hope that this can be
>> revisited. Even if most people who responded earlier in this list
>> decided that they were happy with the current state, it represents a
>> tiny fraction of people using the language, and at least all the
>> people I talked to strongly disagree but just aren’t on the list.
>> 
>> Right now access control is file based and not API based. This is much
>> easier to implement but useless to express that certain elements of a
>> class are implementation details that are not meant to be used
>> anywhere else (someone can add more code to the same file and get
>> access to the implementation details without modifying the
>> class). 
> 
> I agree that our current access control has real weaknesses, but I don't
> agree you've identified one above.  Anyone who can "add more code to the
> same file" can just as easily modify/extend the class.  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.
> 
> I'm going to let others respond to the rest of this in more detail, but
> I should also add that 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.
> 
>> It’s also impossible to hide APIs that are meant only for
>> customization points of subclasses.
> 
>> Some of these problems could be solved with a convention like putting
>> _ in front of protected and __ in front of private methods, and Cocoa
>> uses a similar approach today. But this “solution” is in the same
>> category as using prefixes to determine types. If Swift aims to have a
>> strong type system, and it’s described as one of advantages of Swift
>> over ObjC, it should help enforce this at the language level.
>> 
>> .NET has a good solution that respects the OOP terminology and deals
>> with accessibility in modules and at the API level:
>> https://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx
>> 
>> I think that a similar approach would work much better in Swift.
>> 
>> —
>> Ilya Belenkiy
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> Cheers,
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160123/9374d706/attachment.html>