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

[Matthew Johnson]

> On Apr 7, 2017, at 10:32 AM, BJ Homer <bjhomer at gmail.com> wrote:
> 
> 
> On Apr 7, 2017, at 9:23 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
> 
>> The most common thing is to have some stored properties that are private and include a handful of fileprivate (or higher) methods that operate on these properties in the type declaration.  All members that don’t need direct access to these properties are placed in extensions specifically to prevent the direct access to stored properties which they don’t need.  This minimizes the lines of code with access to such properties.
> 
> Is there a reason this could not be implemented by putting all the sensitive stored properties in a separate type from the rest of the code?

This has already been discussed extensively in the threads.  The problem with this approach under the current proposal is that there is no way to hide that type or its members from the rest of the file.  It can be extended anywhere in the file which means the kind of encapsulation intended by users of scoped access is not really available.  This is a kind of half-solution that relies on not extending the separate type and therefore offers a weaker guarantee while requiring extra boilerplate.  It is also a kind of half-solution for those who wanted to revert SE-0025.  

Setting aside source compatibility concerns for a brief moment, is there anyone who would choose this approach over reverting SE-0025, renaming the current modifier, or maintaining the current access modifiers?  If this is nobody’s first choice that should be a big cautionary sign.  It would indicate that this is the result of “design by committee” where nobody really likes it and it is at best the closest to consensus we could get.  I don’t think “this is the best we can do because of source compatibility” is an appropriate justification for accepting this kind of solution.  If source compatibility is such a paramount concern we should probably maintain the status quo or keep looking for a better, more source-compatible solution in the future (probably Swift 5).

I think one of the goals for Swift is to try and avoid that kind of decision making.  If I’m going to be dissatisfied with part of the language I would rather it be for some other reason than that SE has caused the language to suffer from “design by committee” kinds of flaws.

> 
> -BJ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170407/8ed292df/attachment.html>