Forgive me for creating a new thread, I don't know how to reply to an
archived discussion (I just registered to the mailing-list).
There are two reasonable options here:
1. Allow both `private` and `fileprivate` at file scope despite the fact
that they have the same meaning. This is more consistent in the sense that
we are not introducing a special case that arbitrarily prohibits an
otherwise valid access modifier. It also means that nothing needs to
change for top level `private` declarations in existing code.
2. Prohibit `private` at file scope. Given that it appears as if the
behavior of `private` at file scope may not be intuitive and is equivalent
to `fileprivate` it might be reasonable to just disallow it. This would
result in more consistent *code* (even if there needs to be a special case
in the language).
I don’t have a strong opinion on which option we choose. But I do feel
strongly that the semantics of `private` need to properly respect the scope
in which the keyword is written and into which the associated declaration
is introduced (rather than the scope *inside* the declaration it is
The way we are defining those makes `fileprivate` closer to `internal` than
* `fileprivate` and `internal` have a predefined scope level (the file, the
* `private` has a scope level depending on where it is declared
It would be more consistent to:
a) either rename `fileprivate` to `fileinternal`
b) either scoping `internal` keyword explicitly with a naming like
With this in mind, I wouldn't choose solution 2 from *Matthew* (prohibiting
`private` at some scope level), I would choose solution 1, with room for
renaming `fileinternal` in the future.
-- Antoine Cœur
On *Wed Jun 15 15:09:52 CDT 2016, **Matthew Johnson* matthew at anandabits.com <swift-evolution%40swift.org?Subject=Re:%20Re%3A%20[swift-evolution]%20[Discussion]%20A%20Problem%20With%20SE-0025%3F&In-Reply-To=<BD9FE13B-87B0-4CFB-9745-6C2DF506FE79%40anandabits.com>> wrote: