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 
access level.

https://developer.apple.com/swift/blog/?id=11 
<https://developer.apple.com/swift/blog/?id=11> 

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 
> <swift-evolution@swift.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 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.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 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> @Daniel
>> 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 
>> semantics.
>> 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:
>> 
>> Current:
>> fileprivate(set)
>> 
>> Suggested:
>> private(file)(set)
>> 
>> Still, of all the hurdles one might face, this one I believe is definitely 
>> the one that poses the less threat!
>> 
>> @Tino
>> 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.
>> 
>> Best,
>> Gonçalo
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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

Reply via email to