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.
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
