[swift-evolution] [Discussion] fileprivate vs. private(file)

[Xiaodi Wu]

I'm terribly sorry to be _that guy_, but I have to interject that
`private(file)` was discussed extensively during review for SE-0025, that
the full scheme laid out in the first message of this thread was given
consideration, and that the core team took these suggestions into account
before accepting and implementing `fileprivate`.

Now, it has been said that real-world experience opens the door to
reconsidering the substantive content of SE-0025 (as in, whether "new"
private should exist at all). It has also long been said that a superior
name would be considered instead of `fileprivate` if someone came up with
one. But clearly, if hundreds of messages advocating for `private(file)`
did not cause the core team to consider it to be a superior name, it is
exceedingly poor form to keep bringing it up again. It's already exhausting
to bikeshed upcoming features, but this shed has already shipped.


On Mon, Feb 20, 2017 at 11:14 AM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 20 Feb 2017, at 15:25, Ross O'Brien <narrativium+swift at gmail.com>
> wrote:
> Does 'private(module, type)' grant get-set access to external subclasses,
> or get-only?
>
>
> Without a specific set condition it'd be both get and set for both. So you
> might need to do for example:
>
> private(module, set:type) func someMethod() { … }
>
>
> Though this may be assuming that set always implies get; I'm not sure if
> there's a need for set-only access restrictions, as any example I can think
> of that might need it can be handled by a method specifically for that
> purpose.
>
> If I write 'private(file, type)' is the property accessible only to types
> within the module, or outside as well?
>
>
> The property would be accessible anywhere in the same file, as well as
> accessible to any sub-class both in the module and externally.
>
> Are you asking whether it'd be possible to restrict the external access of
> type? This might be an argument for allowing the type parameter on both
> private and public perhaps? So if you want external access to sub-classes
> you'd do:
>
> public(type) func someMethod() { … }
>
> Whereas for internal access you'd do:
>
> public(file, type) func someMethod() { … }
>
> Or are there still cases that aren't covered? It's possible it's a bad
> example of something that can be added to the parameterised form in future,
> and maybe it is something that does still require its own keyword?
>
> _______________________________________________
> 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/20170220/85d6a25a/attachment.html>