> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky 
> <nevin.brackettrozin...@gmail.com> 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 
>> <swift-evolution@swift.org> 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 
>>> <swift-evolution@swift.org> wrote:
>>>>> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>>>>> <swift-evolution@swift.org> a écrit :
>>>>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>>>>> <swift-evolution@swift.org> 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
>>>> swift-evolution@swift.org
>>>> 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
>>> 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

Reply via email to