[swift-evolution] access control

Ilya Belenkiy ilya.belenkiy at gmail.com
Thu Jan 28 05:56:15 CST 2016

"Local" addresses an important problem in the current access control,
should be easy to implement and support,, and doesn't break any existing
code. If you are not going to use it, that's ok, but plenty of people will.
It's the number one complaint that I hear about Swift from anybody I asked
about the language. So I understand "I won't use it", but I don't
understand "I am strongly against".

I also think that 2 rounds of discussion are more than enough to schedule a
review and asked about this. It looks like my question was ignored. I will
definitely keep trying one way or another until it goes through a formal
review. Even if it gets rejected, at least there will be an official
statement about why real data encapsulation is not important enough or
needed for Swift. And if it's accepted, a lot of people who are not on this
list will be very happy.
On Thu, Jan 28, 2016 at 5:56 AM Brent Royal-Gordon <brent at architechies.com>

> > 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). It’s also impossible
> to hide APIs that are meant only for customization points of subclasses.
> I am strongly opposed to `local`. But frankly, I'm so sick of discussing
> it at this point that I think we should just go ahead and propose it.
> Everyone can write their reviews, the core team can make a decision, and
> whatever they decide, we can move on from this topic to more interesting
> things.
> --
> Brent Royal-Gordon
> Architechies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/55122472/attachment.html>

More information about the swift-evolution mailing list