> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky > <[email protected]> wrote: > > Daniel, I would be interested to hear what, exactly, are the benefits your > project has realized from the new “private” compared to the old “private” > (which is now called “fileprivate”). >
There's no amazing insight here. The benefit is more granular control. The more people work on a project, the more useful this becomes. You might as well ask "why not make everything public" if private and fileprivate makes no difference to you. > Were there problems caused by the old “private” that have been solved by the > new “private”? Major problems? Minor annoyances? > > • • • > > As I see it, two significant drawbacks of the new “private” are increased > complexity in the access control model, and encumbrance of the old “private” > with the unwieldy moniker “fileprivate”. > The first drawback is a truism: every language addition of feature makes it more complex. So we need to measure the benefit with other costs, which brings us to your second "drawback". I'm having a hard time understanding it. Is it too hard to type? If so, as an Objective-C survivor I disagree. The experience of reading code is harder and therefore more important than that of authoring code. "fileprivate" was chosen over many other alternatives because it's obvious to the reader. A shorter but equally obvious name would have been nice. But "unwieldy" is not enough reason to justify such source-breaking change at the moment. > If the new “private” has brought real benefits sufficient to outweigh its > complexity cost then I think it should stay, and if not it should go. Thus I > am curious to see what benefits it has in practice. > > • • • > > Regardless of whether the new “private” is pulling its weight, I believe we > should find a shorter name for “fileprivate”. > > And I think Xiaodi has the right idea: whensoever in the future we decide to > introduce submodules, it would be best if they subsumed the file scope. In > essence, a submodule would be the mechanism for parceling out code which > currently must reside in a single file (because it relies on “fileprivate” > which is the old “private”). > > That way a submodule could comprise several interrelated pieces which need to > share privy details, while preserving their natural separation into distinct > files. So it makes sense that we should find a replacement for “fileprivate” > which is copacetic to submodules. > > Actually, now that I write it down, I wonder if perhaps “privy” might work as > a keyword. It is short, it means “being party to shared secret knowledge”, > and its spelling conveys a sense of “private-ish”. > > The other ideas I’ve come up with have shortcomings, such as “local” which > has a pre-existing incompatible meaning in programming (otherwise it would be > great), or “folio” which is not an adjective (and also isn’t ideal for the > single-file case). > > But “privy” just might work. > > Nevin > > >> On Thu, Oct 13, 2016 at 10:44 PM, Daniel Duan via swift-evolution >> <[email protected]> wrote: >> I question the practicality of "use private heavily simply because I don’t >> want the burden of mixing private and fileprivate". In our experience in >> converting a very mature Swift application, we had no choice but to use both >> because we wanted private as much as possible but that's too restrictive in >> some cases. The granularity private and fileprivate provide is definitey a >> welcome change. >> >> Daniel Duan >> Sent from my iPhone >> >>> On Oct 13, 2016, at 3:11 AM, David Hart via swift-evolution >>> <[email protected]> wrote: >>> >>> >>>>> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution >>>>> <[email protected]> a écrit : >>>>> >>>>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution >>>>> <[email protected]> wrote: >>>>>>>> I actually consider it very lucky that most of our changes so far have >>>>>>>> been fairly non-controversial. Everybody has a different idea of what >>>>>>>> would make Swift a better language, and all of us well-meaning. But >>>>>>>> when those ideas conflict, some group is going to end up unhappy. I'm >>>>>>>> actually very glad that (a) we haven't had too many of these cases, >>>>>>>> and (b) even when we have, people have been able to accept it and move >>>>>>>> on to contributing to the next issue. >>>>>>> >>>>>>> >>>>>>> Strong agreement here as well. This proposal has been litigated >>>>>>> numerous times already, and the bar for source-breaking changes is much >>>>>>> higher now. To effectively re-open the discussion would require a >>>>>>> proposal that significant changes the model with a lot of evidence that >>>>>>> such a new model is a drastic improvement over what we have now. “Back >>>>>>> out SE-0025” is not a viable option now. >>>>>>> >>>>>>> - Doug >>>>>> >>>>>> Not really. This proposal could be backed out without source-breaking >>>>>> changes by treating private as a synonym for fileprivate and we’d have >>>>>> Swift 2 behavior without breaking source. If the core team doesn’t want >>>>>> to consider that then we can just move on and live with it. >>>>> >>>>> Not speaking for the core team, just MHO: >>>>> >>>>> I agree with Russ here, and with others who have said upthread that the >>>>> “thing that has changed” is that we are starting to get usage experience >>>>> with fileprivate vs private. I think we all understand the value of >>>>> having fewer access control levels, and so if “private” isn’t >>>>> conceptually pulling its weight, then it is reasonable to consider >>>>> phasing it out. >>>>> >>>>> That said, there is no specific rush to have this discussion, and I think >>>>> it is reasonable to put a pretty high burden of proof on someone who >>>>> wants to drive such a proposal. For example, if we had the discussion in >>>>> the spring timeframe, we should have a pretty large body of Swift 3 code >>>>> readily at hand (e.g. SwiftPM packages and other various github repos). >>>>> >>>>> Given that, it should be easy enough to see how widely private is >>>>> actually being used in practice. If it is very rare, then the argument >>>>> to ditch it (make it a synonym for fileprivate, and eventually phasing >>>>> out fileprivate) is strong. If lots of people are using private and only >>>>> some are using fileprivate, then the discussion is quite different. >>>>> >>>>> -Chris >>>> >>>> I don’t think monitoring the usage of private vs fileprivate is fair. By >>>> default, people will use private until they encounter visibility issues >>>> and discover they need to change to fileprivate. So private will probably >>>> being use far more than fileprivate. >>>> Nonetheless it does not mean people chosen private because it effectively >>>> reduce the visibility to the class scope, but just because it is easier to >>>> discover and to type than fileprivate and fit in many cases. >>>> >>>> I tend to write class will all ivars private by default (as it is a >>>> sensible default), and then, when I start to write extensions and other >>>> parts, I have to switch to fileprivate for a bunch of ivars. It create an >>>> inconsistent mess in my ivars declaration as it is difficult to know if an >>>> ivar is private because I has to be, or because I didn’t encounter a case >>>> that need it to be fileprivate instead. >>>> >>>> Honestly, I don’t see any value in the introduction of fileprivate. >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> I also agree that monitoring the usage of private vs fileprivate is not >>> fair. I now use private heavily simply because I don’t want the burden of >>> mixing private and fileprivate (and find the name of fileprivate slightly >>> verbose/ugly). But that does not mean I would vote for keeping private. I >>> would still vote for going back to Swift 2 behaviour. But I agree that we >>> can wait until the summer to look at this again. >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
