[swift-evolution] private & fileprivate

[Jay Abbott]

I agree that the keywords could be improved, but private(file) access
should not be what 'private' means by itself. If I put just 'private' in
front of something I really mean it should be private to this scope, the
most private. I also think the more common use-case would be private(scope)
over private(file), you might find if you refactor a bit that a lot of your
fileprivate can become private or instead - it's possible that fileprivate
is encouraging you to put things into one file when they should be in
multiple files with a better defined 'internal' API.

I like the *concept* that 'private' is the most private and then it can be
relaxed by modifiers (file) (module) (perhaps-other-stuff), but I'm not
convinced that 'private' is really an appropriate word for something that
is accessible anywhere within a module. Though I agree that 'internal'
doesn't really mean much to someone learning the language, and suffers the
exact same problem (internal to what?) whereas private(module) does express
that a bit better.

On Fri, 7 Oct 2016 at 09:26 Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 7 Oct 2016, at 07:39, David Hart via swift-evolution <
> swift-evolution at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161007/a23037dc/attachment.html>