On Sun, Mar 26, 2017 at 12:57 PM, David Sweeris via swift-evolution < [email protected]> wrote:
> > On Mar 26, 2017, at 08:50, David James via swift-evolution < > [email protected]> wrote: > > I propose instead that we revise to use Alternative #3, per Vladimir’s > comment and revision. > > Revised version: > > *“3. Revert private to be file-based and introduce the scope-based access > level under a new name (e.g.: scoped, local, etc), provided that the > scope-based access modifier is not used at the top level of the file.” * > (addendum via Vladimir’s revised comment) > > > Yeah, within reason, I couldn't care less how "private"/"fileprivate" are > *spelled*. What I'm against is removing the *functionality* of the > current "private" without simultaneously providing a semantically > equivalent replacement. > Conversely, I do not particularly care whether the functionality of scope-based visibility stays or goes, but I find the spelling “fileprivate” to be an ugly wart on an otherwise beautiful language. Before the discussion on this review, I had a slight preference for removing scope-based visibility in order to simplify the access control model. After reading through the thread I have a slight preference for keeping that functionality to enable compiler verification that invariants are only touched via dedicated channels. I do not have a strong opinion either way, and I would be fine to see scope-based visibility exist under the name “scoped”, or be removed entirely. However, the “fileprivate” keyword is one of the few things I actually *dislike* about Swift. As in, when I am writing code I find it annoying and offputting to use such a lengthy and inelegant term for one of the most common access levels. I think it was a mistake to change the meaning of “private” in SE-0025, and we should change it back posthaste. Nevin
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
