> On Feb 16, 2017, at 4:55 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Feb 16, 2017, at 5:42 PM, Sean Heber via swift-evolution >> <swift-evolution@swift.org> wrote: >> Honestly I really think this should be seriously considered. I do use >> private and fileprivate and such myself *because it’s there* and as a result >> it feels like I should - but I shudder to think how much brainpower I’ve >> wasted(?) on deciding which one to use when. I strongly suspect that the >> degree of the benefits of all these access levels is not as significant as >> it seems on the surface. > > I think this applies more to private vs. fileprivate. Having *some* way to > mark something as private — if nothing else, to tell other programmers > (including Future You) to think twice before using it directly — is pretty > useful in a large project. But having finer shades than that does seem to > just cause mental anguish.
As I have said elsewhere, I think the mental anguish mostly derives from the fact that scoped private is not the right “default” in a language that uses extensions pervasively. Chris’s suggestion of having private mean “same file *and* same type” would be a good default. But if we’re not willing to *also* have fileprivate then the Swift 2 definition of private is the best “default’. I still think scoped access control is valuable but taking `private` as the keyword for this was a mistake. I’d like to see us take another stab at identifying a suitable name for it. That said, I get the feeling that not too many others have appetite for this so it may be a lost cause... > > John. > >> >> l8r >> Sean (who has no actual data) >> >> >>> On Feb 16, 2017, at 4:34 PM, Slava Pestov via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> While we’re bikeshedding, I’m going to add my two cents. Hold on to your >>> hat because this might be controversial here. >>> >>> I think both ‘private’ and ‘fileprivate’ are unnecessary complications that >>> only serve to clutter the language. >>> >>> It would make a lot more sense to just have internal and public only. No >>> private, no fileprivate, no lineprivate, no protected. It’s all silly. >>> >>> Slava >>> >>>> On Feb 15, 2017, at 7:40 AM, T.J. Usiyan via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> "Either keep it or drop it, but don't keep fiddling with it." sums up my >>>> position well. >>>> >>>> On Wed, Feb 15, 2017 at 7:00 AM, Brent Royal-Gordon via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>>> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> Keeping with the spirit of Swift and staying consistent with its design, >>>>> I see two plausible meanings for private: >>>>> >>>>> Private could mean either: >>>>> 1) private to the file (Swift 2 semantics) >>>>> 2) accessible only to the current type/scope and to extensions to that >>>>> type that are in the current file. >>>>> >>>>> I don’t think we’ve ever evaluated and debated approach #2 systematically. >>>> >>>> For what it's worth: >>>> >>>> I was opposed to SE-0025, but since I lost, I have tried to use `private` >>>> wherever it made sense, rather than fighting with the language. >>>> >>>> Sometimes, the change of keyword makes no difference. Other times, it's a >>>> hassle, because I have to switch between `private` and `fileprivate` as I >>>> redesign things, with little perceived benefit. I'd say the split between >>>> these is about 50/50. >>>> >>>> On a few occasions, I *have* genuinely appreciated the SE-0025 version of >>>> `private`. These involved cases where I wanted to ensure that instance >>>> variables were only manipulated in certain ways, using interfaces I had >>>> specifically designed to handle them correctly. For instance, I might have >>>> two parallel arrays, and I wanted to make sure that I only added or >>>> removed elements from both arrays at once. I could do this with >>>> `fileprivate` by splitting the type into two files, but it was more >>>> convenient to do it in one. >>>> >>>> In these cases, switching to #2 would *completely* defeat the purpose of >>>> using `private`, because the extensions would be able to directly >>>> manipulate the private instance variables. I would no longer gain any >>>> benefit at all from `private`. All of my uses would either fall into >>>> "makes no difference" or "it's a hassle". >>>> >>>> I do not support the idea of changing `private` to mean #2. Doing so would >>>> eliminate the few decent use cases I've found for `private`. Either keep >>>> it or drop it, but don't keep fiddling with it. >>>> >>>> -- >>>> Brent Royal-Gordon >>>> Architechies >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution