<div dir="ltr">I&#39;m not sure of my own opinions on this one as I can see good points on both sides. There also seem to be a variety of different discussions with similar concerns. So at the risk of confusing things I&#39;m suggesting another idea, with the hope/intention of promoting some deeper thought and helping us figure out what is needed/wanted.<br><br>I will use the word &#39;sheltered&#39; here, apologies if that is confusing, it just means protected/hidden/whatever but without any existing notions of what those might mean. It might not be the best word either, I just picked it from a list of synonyms for &#39;protected&#39;.<br><br>Class authors can (now) if they want provide their own way to explicitly access some private members through a public interface:<br><div><br>public class Thing {<br>    private var x: Int<br>    public var shelteredX: Int {<br>        get { return x }<br>        set { x = newValue }<br>    }<br>}<br><br></div><div>But this isn&#39;t ideal as it just causes excess boilerplate code and doesn&#39;t hide it from anyone or suggest they shouldn&#39;t normally use it (other than the explicit naming). However, perhaps the compiler could help with this type of pattern as follows:<br><br><div>public class Thing {<br>    sheltered var x: Int {<br>        get { return x } // not sure how this would work - x is also the backing ivar so you don&#39;t have to declare it twice as _x and x.<br>        set { x = newValue }<br></div><div>    }<br></div><div>   // accessors provided - internal access to x is direct, sheltered access is via accessors<br></div><div><br></div><div>    sheltered var y: Int<br></div><div>    // No accessors provided, sheltered access to y is direct<br></div><div>}<br><br></div></div><div>For members with &#39;sheltered&#39; access:<br></div>* Don&#39;t by default allow access to the sheltered members or accessors - they are equivalent to private (or maybe fileprivate)<br><div>* Provide a way to expose them in a given scope<br></div><div>* I think it can be applied to methods too<br></div><div><br></div><div>For example:<br></div>var aThing = Thing()<br><div><div>aThing.x = 7 // NOT ALLOWED: x is sheltered.<br></div><div>@unshelter(aThing) // aThing is unsheltered in the remainder of its scope.<br></div><div>aThing.x = 7 // NOW ALLOWED<br></div><div><br></div></div><div>One good thing is that this is very explicit where you use it.<br><br>Sheltered groups might also be a thing:<br><br></div><div>Definition:<br></div><div>sheltered&lt;Subclasses&gt; var x: Int<br></div><div><div>sheltered&lt;Wotsits&gt; var y: Int<br></div>Usage:<br></div><div>@unshelter&lt;Subclasses&gt;(aThing)<br></div><div>// x is available, y isn&#39;t<br><div>@unshelter&lt;Subclasses, Wotsits&gt;(aThing)<br></div>// x and y are available<br><br></div><div>&quot;Subclasses&quot; and &quot;Wotsits&quot; are author-defined identifiers, not keywords.<br></div><div>This is a bit like friends and protected, but using an honesty system, where friends can easily declare themselves as friends by unsheltering all the Wotsits group, and subclasses (not enforced) would unshelter the Subclasses group. That is, the author&#39;s intentions are clear, but other classes can abuse it to get access. If the author doesn&#39;t want to allow abuse, they can do this:<br><br><div>Definition:<br></div><div>sheltered&lt;Subclasses: Thing&gt; var x: Int<br></div><div><div>sheltered&lt;Wotsits: Wotsit&gt; var y: Int<br></div><div><br>Usage:<br></div></div><div>@unshelter&lt;Subclasses&gt;(self); or<br>@unshelter&lt;Subclasses&gt;(anOtherThing)<br></div><div>// Works inside a Thing subclass, x becomes available. The scope in which @unshelter is used must match the type of the shelter group.<br><br></div><div>@unshelter&lt;Wotsits&gt;(self); or<br></div><div>@unshelter&lt;Wotsits&gt;(aWotsit)<br></div><div>// Inside a Wotsit or a Wotsit subclass this would work, y becomes available.<br></div><div><br></div>I&#39;m just spitballing here, this isn&#39;t fully thought through. Perhaps a where clause would be better instead of a type annotation for the shelter groups, so you could list multiple types that are allowed to unshelter that group. You might be able to abuse it still by putting something in an extension of an allowed class, so that may need some further thought.<br><br></div><div>This is of course more complex that other proposed solutions, I&#39;m just trying to combine all the desires people seem to have and see what people think - do we want more control and are happy with a bit more complexity? or should it be simple and less control? Personally I actually don&#39;t have much of an opinion on it because I haven&#39;t used Swift enough yet to come a cropper of such things.<br><br></div><div><br></div></div>