[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi]

Sent from my iPhone

> On 24 Mar 2017, at 05:36, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I agree with everything you wrote here. And it is for that reason that I would expect that any future proposal for submodules should be judged in no small part on its _not_ changing circumstances surrounding access modifiers, such that no further proposals to revisit this topic will come up. It's one thing to have one-off discussions to back out a change that in hindsight seems unwise; it's quite another to have the community return to the same topic over and over like this. No more. Let's do this never again.

It was not the people using and liking private's scope based visibility which brought this proposal forward and should be punished because of it.
I can understand what you are saying and where you are coming from, but it is not an argument strong enough to justify removing this access level for IMHO, quite the opposite really. 
Also, I do not think the core team would not want to revisit this/accept to revisit this once a good submodule design like the one Rust has were to be implemented into Swift.

>> On Fri, Mar 24, 2017 at 00:04 Drew Crawford <drew at sealedabstract.com> wrote:
>>>> Or, since many designs for submodules are possible... confident that there will be a good design for submodules
>>> 
>>> We lack any real information on what Swift designs are possible.  We can look to other languages for inspiration but they cannot be transplanted wholesale into Swift from a technical, practical, or cultural perspective.  Rust isn't Swift.
>>> 
>> 
>>> Given, as some have said above, many different submodule designs are possible whatever the number of access levels, I would expect that we would not revisit this topic again for the foreseeable future, whatever the decision is.
>> 
>> I think it would be appropriate to revisit this if we have new information.  You have previously argued that there is substantial new information which you present as a rationale to revisit it now.  I don't accept the premise, but I do accept the argument: if the circumstances change it's appropriate to take another look.
>> 
>> 
>>> On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution (swift-evolution at swift.org) wrote:
>>> Or, since many designs for submodules are possible, we can proceed to make the best decision *now* with respect to access levels, confident that there will be a good design for submodules whether or not there exist both scoped and file-based private access. That is to say, any future submodule proposal would be judged on how well it accommodates desired use cases if one type of private is removed, and any future design for submodules would be judged on how well it fits with the current set of access levels without duplicating functionality with a different syntax if both types of private are retained.
>>> 
>>> One very important thing about the evolution process (IMO) is that decisions made aren't revisited without compelling changes in circumstances. It is highly unusual that fileprivate vs. private is now going through this process for a _third_ time. I submit that it is untenable that every version of Swift should consider a change to the access modifiers. Given, as some have said above, many different submodule designs are possible whatever the number of access levels, I would expect that we would not revisit this topic again for the foreseeable future, whatever the decision is. That is, the question being asked here is, is it better for Swift to have both fileprivate and private for all time, or one file-scoped private for all time?
> _______________________________________________
> 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/20170324/edbb1efc/attachment.html>