I’m +1 on the following: current new private private fileprivate private(file) internal private(module) public public open open The only thing that keeps bothering me is private(set) and how it will harmonize with this proposed scheme.
Regards, Adrian Kashivskyy > Wiadomość napisana przez David Waite via swift-evolution > <[email protected]> w dniu 07.10.2016, o godz. 17:54: > > I'd prefer to use public(file), etc over private. You are determining which > code has access over which code doesn't. I don't think its that confusing to > say the default is just public(module) > > Sent with my Thumbs > > On Oct 7, 2016, at 9:21 AM, Xiaodi Wu via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> While no topic is formally off the table, to revisit a topic requires fresh >> insight. `private(file)` was suggested at the time and rejected in favor of >> `fileprivate`, and we really don't need another rehash of how much each >> person likes one or the other. >> On Fri, Oct 7, 2016 at 09:02 Adriano Ferreira via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> +1 >> >> I would also rather have: >> >> private(scope) >> private(file) >> private(module) >> etc… >> >> — A >> >>> On Oct 7, 2016, at 4:24 AM, Haravikk via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On 7 Oct 2016, at 07:39, David Hart via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Hello community, >>>> >>>> From all the proposals which has gone into Swift 3, [SE-0025] Scoped >>>> Access Level is the only one I’m having second thoughts about. Before >>>> launching a discussion around it, I’m curious to know if it's worth >>>> discussing it or if the “ship has sailed”. As the plan is to allow future >>>> versions of Swift to break source-compatibility in certain rare scenarios, >>>> perhaps we have a chance to reconsider certain proposals? >>>> >>>> Regards, >>>> David. >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> What in particular don't you like about it? >>> >>> Personally I still don't like the use of fileprivate as the keyword, I was >>> very much in favour of a bracketed system like: >>> >>> private(scope) Current private (I think, it doesn't appear to >>> be equivalent to protected in other languages anyway so I wouldn't call it >>> type). >>> private(file) Current fileprivate >>> private(module) Current internal/default when omitted >>> public Current public >>> >>> I favour this because it groups all restrictive access levels under private >>> (since they're all some form of private) with an optional modifier that's >>> explicit about what it's for. Also, it would have scope to move things like >>> final into a modifier too, so you might declare a method as public(final), >>> or public(open) if that's implemented later and so-on. Just seems like a >>> generally more flexible setup that also reduces the number of keywords >>> required. >>> >>> Some may feel it's noisy, but personally I don't see it as a problem as it >>> always comes before the func/var/let keyword, generics and function name, >>> so it's not like it's near anything where the (minor) noise reduces >>> readability. >>> >>> But yeah, having used the new fileprivate for a little while I just don't >>> like it; it may partly come down to the fact that I use fileprivate a lot >>> more than I use regular private. If we were to adopt the above scheme I >>> would recommend that private(file) be the default for use of the plain >>> private keyword, unless we gain the ability to specify private(type) (i.e- >>> protected in most other languages), as private(scope) seems like it's the >>> less common, at least in my experience. >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
