[swift-evolution] access control

[Dave Abrahams]

on Sat Jan 23 2016, Ilya Belenkiy <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
> https://lists.swift.org/mailman/listinfo/swift-evolution

Cheers,

-- 
-Dave