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. On Fri, Mar 24, 2017 at 00:04 Drew Crawford <[email protected]> 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 ( > [email protected]) 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
