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