[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Aron Lindberg]

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 at 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 at swift.org <mailto:swift-evolution at 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 <daniel at crossroadlabs.xyz <mailto:daniel at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/20161201/b4854c4c/attachment.html>