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

[David Hart]

> On 6 Apr 2017, at 19:41, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi, -evolution. I’ve said this before, but I think this new proposal is a terrible idea. It privileges types in a way that is damaging to the language.
> 
> [There isn't really anything new in my discussion below; everyone on-thread is smart enough to have brought up these points already. But I wanted to go on record about it, at least.]
> 
> The claimed problem with the current version of 'private' (let's call it "scoped-private") is that it encourages developers to make monolithic type declarations instead of using extensions. With the proposed new interpretation (let's call it "extension-file-private"), there's a similar problem: developers are encouraged to put everything in the original type even when it may be more appropriate to
> 
> 1. Extend another type (e.g. converting initializers)
> 2. Use a helper type (a nested type always inherits the generic parameters of its enclosing type)
> 3. Break a single protocol or class out into a hierarchy (subtyping should be used sparingly but not never)

I don’t get that impression. Even with this proposal, fileprivate is readily available to share implementation details with other types in the file. I view this proposal’s version of private very similarly to private in other languages (extensions in the same file as the type feel like part of the type’s scope to me).

> Of course, one can always add an extension to access the extension-file-private members from outside the type, but that just underscores how little expressive power this level would actually have. These are cases where 'fileprivate' is the correct tool for the job.

I don’t feel like this proposal reduces the usefulness of fileprivate, it just makes private more attractive more most cases (i.e., it’s not because public is a good soft-default that open is any less useful).

> I liked the original three levels of access (not a surprise to anyone, since I was a primary designer), and one reason for that is that the access levels are completely indepedent of the declarations you're writing. You can organize your code in whatever way makes the most sense, and the access levels will then help you enforce that organization. I do think SE-0025 should not have been accepted, that it does not add enough benefit given the increase to complexity, but even scoped-private can be used as an organizational feature that prevents you from making mistakes, and it still offers a simple answer to where a declaration can be used.

Speaking for someone who uses extensions extensively, I’ve found very little use for private in my own code.

> The proposed extension-file-private exposes a declaration to an arbitrary subset of the file it's in, because being within an extension of a type or not is arbitrary with regards to code organization. Extensions are used organizationally, but there's now no way to distinguish whether the private members of this extension are related to the private members of that extension, or whether they were supposed to be independent.
> 
> Everyone is acting like "fileprivate" is a problem. While we may not like the name, it's still the right tool for the job. What else do you have in the file that you're trying to protect?

If it’s the right tool for the job, then the goal of SE-0025 to make private the soft-default and file private used in rarer occasions have failed. And that’s how I see this proposal: as trying to fix this original goal.

> Let's not add a mishmash of a feature just because it's "practical" for some uses.
> 
> Thanks for hearing me out,
> Jordan
> 
> P.S. I have a lot to say on the idea of "submodules", and the dozen different things people want from them. I'll try to write that up later, so that people can refer to it if/when we ever get around to discussing such features. But it's not relevant right now.
> 
> _______________________________________________
> 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/20170406/36ef5173/attachment.html>