I know it is a little old, but this is a nice read about the motivation for
Swift's original access modifiers and why 'Protected' was not defined as an
I think the point here is that access levels have been a heated topic since
before Swift 1.0
> On 1 Dec 2016, at 17.12, Xiaodi Wu via swift-evolution
> <firstname.lastname@example.org> wrote:
> This discussion has been had on this list several times already. Using a name
> other than fileprivate, in particular, was part of the original discussion
> and the core team selected the current spelling.
> As Tino mentioned, submodules are a topic that the community has already
> expressed some interest in incorporating in the future and is listed as a
> possible topic by the core team for Swift 4 stage 2. At that time, it would
> seem obvious that submodule access levels would be introduced. It seems that
> this idea would be largely duplicative of that functionality, and it would
> destroy the current deliberately chosen file-based design for access levels.
> On Thu, Dec 1, 2016 at 08:42 João David via swift-evolution
> <email@example.com <mailto:firstname.lastname@example.org>> wrote:
> @Daniel, agree.
> Sent from my iPhone. Erroneous words are a feature, not a typo.
> On 1 Dec 2016, at 14:23, Daniel Leping <dan...@crossroadlabs.xyz
> <mailto:dan...@crossroadlabs.xyz>> wrote:
>> Gonçalo, I can suggest a bit different API to avoid clashing. Something like:
>> private (file, set)
>> Instead of:
>> private (file) (set)
>> Looks easier to me as it poses a possibility just to list the attributes in
>> a pretty much standard way.
>> On Thu, 1 Dec 2016 at 16:15 Gonçalo Alvarez Peixoto via swift-evolution
>> <email@example.com <mailto:firstname.lastname@example.org>> wrote:
>> I am very fond of your idea, as I believe it add extra flexibility to this
>> solution, as Álvaro mentioned. My only concern is somehow related to
>> Should we add the extra scope detail as you suggest, then it could clash
>> with the current way of setting a setter as private or fileprivate:
>> Still, of all the hurdles one might face, this one I believe is definitely
>> the one that poses the less threat!
>> As you imply on a previous email, this solution might even facilitate the
>> introduction of new levels of access control all throughout modules, whether
>> internally and externally. While I do agree complexity does raise an issue
>> in designing a fine solution for access control, I insist this concern
>> should not block the language's evolution into finer grained control and
>> better focused levels of scope. Quoting Álvaro: "communication is something
>> that everyone agrees is a essential in swift and access control is one of
>> the many ways developers have to properly describe (and communicate) an API."
>> Also Tino, you state:
>> "The question for me is how much complexity should be accepted as a tradeoff
>> for increased expressiveness?
>> "private, internal, public" was quite simple, but the current system is
>> already quite complicated, and it doesn't scale well."
>> In fact, I consider this change a great opportunity for the current system
>> to be revisited in a gradual manner.
>> As to the equatable issue you pointed out, is there a reason why replacing
>> the fileprivate access control level by with a typeprivate would not solve
>> the problem raised with private?
>> There's yet another issue I would like to reinforce, one raised on previous
>> emails. As stated before, I do believe fileprivate, as a compiler related
>> construct, opens the door for one to access members from another member, as
>> long as they'r all sitting within the same file. This creates conditions for
>> a odd and dangerous pattern. While I don't think fileprivate aims at
>> promoting several type implementation within the same file, it certainly
>> opens that door. That's one pattern a typeprivate access control level would
>> grant no advantages in using.
>> swift-evolution mailing list
>> email@example.com <mailto:firstname.lastname@example.org>
> swift-evolution mailing list
> email@example.com <mailto:firstname.lastname@example.org>
> swift-evolution mailing list
swift-evolution mailing list