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

[João David]

@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> 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> 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
>> 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/a6889572/attachment.html>