------------ Begin Message ------------ Group: gmane.comp.lang.swift.evolution MsgID: <CAAgRLFOjfhHdG3xe1eqPVWcZsx0n5CfO2QvxgoEhj_=utt4...@mail.gmail.com>
if they really want it they will make an extension (which would be a legitimate use of it) if they don't need it really - they will find another way without making an extension. the (reasonable) expectation is that such a "classprivate" will reduce the number of instances where "foo" is used thus reducing the "working set" of instances i have to review when making a change to it. ------------- End Message ------------- This first point is the key issue. Any internal-scope usage can be trivially converted into an extension, so the ‘access control’ here is simply making it less discoverable. The ‘pure’ access levels of fileprivate and internal truly CANNOT be worked around in this way without access to the original file/module, which may be withheld. That said, there is precedent for this kind of modifier already - it seems to me the current ‘private’ access level is to fileprivate what this is to internal. With private, you still have to search the whole file for extensions; the benefit is having autocomplete be less cluttered elsewhere in the file, and the hint to the developer to consider usage more carefully. From that perspective, where private is a scoped fileprivate, a scoped version of internal makes a good deal of sense. For what it's worth, I'd consider typeprivate a good name for this. However the introduction of the new 'private’ was highly controversial in itself, even with the advantage it had over this proposal by being a solution for access control in Playgrounds. While I respect your support for this, I don't thing this proposal will get very far given the circumstances. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
