On 05.04.2017 18:21, Chris Lattner wrote:
On Apr 5, 2017, at 4:31 AM, Vladimir.S <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
