> On Oct 7, 2016, at 9:13 AM, David Hart via swift-evolution > <[email protected]> wrote: > > To summarise, it seems that the confusion the proposal brought over semantics > and style are not worth the limited benefits that it brought. I’d be tempted > to backtrack the proposal and re-introduce private as a file scoped > access-level and deprecate fileprivate.
This is my personal preference, to back out the fileprivate/private change before Swift becomes any more crystallized. That being said, I think the bar for 'novel insight' has to be very high for something like this to be a wise idea, lest we end up endlessly revisiting every idea that wasn't unanimously popular. Do we have any evidence the new access control system is proving a hindrance to developers, or specific information we didn't have during the original discussion? Austin > > Thoughts? > David. > >> On 7 Oct 2016, at 17:21, 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 > > _______________________________________________ > 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
