[swift-evolution] Type-based ‘private’ access within a file
svabox at gmail.com
Wed Apr 5 10:58:59 CDT 2017
On 05.04.2017 18:21, Chris Lattner wrote:
> On Apr 5, 2017, at 4:31 AM, Vladimir.S <svabox at gmail.com
> <mailto:svabox at gmail.com>> wrote:
>>> From a pragmatic perspective, I feel like this is a great solution that
>>> really does solve the problems we have with current access control, all
>>> without breaking source compatibility. This is also a major progression
>>> from where we are, and doesn’t appear to cut off any future directions
>>> (e.g. submodules) since those are cross-file concepts that live between
>>> internal/public or between fileprivate/internal.
>> If we have Swift2's 'private' (instead of fileprivate) and
>> 'scoped'(instead of current 'private'), then such 'private' can naturally
>> mean "private to submodule" *especially* if file will be treated as
>> un-named submodule.
> As John McCall said up thread, introducing new keywords like “scoped” is
> out of bounds for Swift 4.
And as also was mentioned, will never be in bounds for any other versions
of Swift, and currently is a last chance to change anything or keep it as
is. This is why we are discussing if we can revert to Swift2's 'private'
and keep current private in form of 'scoped'(as keyword accepted by many in
And actually the question was if current decision(to keep 'fileprivate' and
extend meaning of 'private') has no obvious drawbacks for access model of
future implementation of submodules, if core team did discuss this, if they
have some opinion/thoughts regarding this etc..
Extend Swift2's 'private' to mean 'private to submodule' seems like
natural, clear and easy to understand/tech solution. Extend Swift4's new
extended 'private' to this meaning is not an option. Yes, it can be
extended to "..in same file AND in same submodule", but additionally we
need a submodule-wide access level. New keyword? Will 'fileprivate' has any
sense inside a submodule at all? etc..
I believe community/core team should discuss such questions even we have no
concrete submodules proposal on the table, i.e. discuss possible future
directions that can depend on changes we are making today.
More information about the swift-evolution