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

[Vladimir.S]

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 
community).

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.

>
> -Chris