"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".<br><br>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.<br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 28, 2016 at 5:56 AM Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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.<br>
<br>
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.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</blockquote></div>