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]> 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]> 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]> wrote: >>>> >>>> >>>> On 7 Oct 2016, at 07:39, David Hart via swift-evolution >>>> <[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] >>>> 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] >>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
