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

[Xiaodi Wu]

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 <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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/d9cdc274/attachment.html>