[swift-evolution] Type-based ‘private’ access within a file

Wed Apr 5 11:00:43 CDT 2017

> Am 04.04.2017 um 01:55 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org>:
> 
>>> On Apr 3, 2017, at 3:07 PM, David Hart <david at hartbit.com> wrote:
>>> 
>>> On 3 Apr 2017, at 23:55, Brent Royal-Gordon <brent at architechies.com> wrote:
>>> 
>>> If that's the case, I don't think we should change the definition of `private` to something so unproven, and which violates our access control design's principles so much, right before the deadline. We do at least know that scoped `private` has some uses; we have no idea if file-and-type `private` will, but we *do* know it will eliminate many of the uses we've found for `private` (like ensuring that only a limited set of methods can use a property with tight invariants.)
>> 
>> It’s not necessarily unproven. It’s actually much closer to what private in other languages look like (with Swift extensions in the mix).
> 
> Sure, but extensions are precisely the reason why `private` is complicated in Swift. That's a bit like saying "we should use integer string indices because they work just fine in languages without good Unicode support".
> 
>> And it would still allow many uses of private, like Drew Crawford’s ThreadsafeWrapper example from the 23rd of March.
> 
> That's great, but the goal is not "Don't break Drew Crawford's one example from the review thread". The goal is "provide a set of access levels which provide appropriate degrees of protection for many use cases".
> 
> To talk about concrete examples, here's a SortedDictionary type I wrote: <https://gist.github.com/brentdax/106a6a80b745bd25406ede7a6becfa30> It has a pair of `private` properties called `_keys` and `_values`, whose indices have to stay in sync. To enforce that invariant, it uses `private` to ensure that only a few primitive members have direct access to the properties in question. Changing `private` to be file-and-type-based would render that protection useless.
> 
> Now, I could redesign this to wrap `_keys` and `_values` plus the privileged members in a separate type, but that type would be wholly artificial; it would have no meaning of its own, and would exist solely to get a certain access control behavior.

I'm not sure of that: I do not think that the type would be artificial but rather that it would be a good example of OO design where a type has a certain responsibility (here: guaranteeing that _keys and _values always stay in sync).

> One effect would be that I'd have to write the `startIndex` and `endIndex` properties twice, increasing boilerplate for no good reason.

Maybe having a more useful `private` is a good reason in itself? As I understand the proposal

`private` is for declaring scopes within a type (instead of over part of a type like currently),
`fileprivate` is for declaring scopes over a few very closely coupled types,
`internal` is for declaring scopes over many types which are coupled more loosely.

So the distinction between `private` and `fileprivate` would still be useful and I tend to think that the proposed change to `private` is more useful than its current strict meaning. 

-Thorsten 

> This is one of those places where scoped `private` really *is* just what I want, and type-and-file `private` really, really isn't.

> 
>>> I also think that allowing stored properties in same-file/same-module extensions will significantly improve the usefulness of `private` and reduce the need to have a same-type-same-file `private`. Right now, the fact that `private` properties can only be used from the main declaration requires that all types using `private` state be stuffed into that declaration. But it doesn't have to be that way, and once it is, `private` won't feel quite so restrictive.
>> 
>> I think that would not help. We would still be constantly juggling between private and fileprivate depending if we are trying to access a property in the same scope or not. When writing types as a minimal internal interface followed by a set of grouping and conformance extensions, you would still constantly bump against limitations of private and resort to fileprivate.
> 
> I look at this the opposite way: If you do not sometimes have to switch a `private` to `fileprivate` or vice versa, then `private` and `fileprivate` are basically synonyms and we ought to accept SE-0159 just to simplify the language. If, in your chosen coding style, `private` and `fileprivate` are almost always synonyms, then it's a distinction without a difference, cognitive load that doesn't bring any benefit.
> 
> IMHO, the "I have to switch back and forth" argument is a good reason not to have two different sub-file access levels because it suggests that the distinction being made is too fine. It's not a good reason to loosen one of the sub-file access levels so it looks more like the other, which only makes the distinction even finer.
> 
>>> (Besides, since we currently can't have two different `private` symbols on the same type in the same file, making this change later would be source-compatible except for overload resolution. We can open that box any time we want, but once we do, we can't close it again.)
>> 
>> John McCall stated this is the last opportunity to improve the status-quo:
>> 
>> I agree.  This is why we asked swift-evolution to consider this last tweak: it is realistically the last opportunity to do it.
> 
> And I'm pushing back on that, because there is no technical reason I can discern why we can't go from scoped `private` to file-and-type `private`. Perhaps there's a social reason—the core team won't want to change access control semantics once Swift is more stable and popular, or they think this topic is a giant ongoing distraction and want to settle it once and for all so they can declare it off-limits forever—but I don't think we should make a speculative change to yet a third design right before we do that.
> 
> Honestly, I think it's becoming increasingly clear that no access control design will ever satisfy everybody. So let's lock down the unsatisfactory design we know, rather than the unsatisfactory design we don't.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/43197f25/attachment.html>