[swift-evolution] private & fileprivate

[Kevin Ballard]

On Fri, Oct 14, 2016, at 02:54 PM, Nevin Brackett-Rozinsky via swift-evolution wrote:
> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan <daniel at duan.org> wrote:
>>
>>
>> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky
>> <nevin.brackettrozinsky at 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.
>>
>
> More granular control *within a single file*. That is where I have a
> hard time imagining the benefits, and thus am asking for details.
>
> If there are multiple types within a single file, it is usually
> because they need to share implementation details.

Just because they need to share some implementation details doesn't mean
they should share all of them. Or better yet, a private/fileprivate type
in a file doesn't have to share any implementation details, it can
define a proper API that it exposes to the rest of the file while
keeping its implementation details private, just as it would if it were
an internal or public type.

> The only things that I see which scope-based access (the new
> “private”) brings to the table are:
> • Scope-private members from other parts of the file are unavailable
> (and thus don’t show in autocomplete).
> • Different extensions of a type can have scope-private members with
> the same name as each other.
>
> The former seems negligible, because you are working *within the same
> file*. The API that a type vends within its own file is hardly worth
> optimizing for.
>
> And the latter I would say is an anti-feature. Using multiple
> different members with the same name in extensions just makes it
> harder to rearrange the implementation, because those scope-private
> members will collide if moved into the same extension.
>
> So I *really* don’t see the benefits. Yes, I understand that there is
> now more granular control over access within a single file. I am
> asking for examples of how that additional granularity provides
> *benefits*.

Just because you're within a single file doesn't mean you need to throw
away the principles of API design. Sure, it's not nearly as important as
something that's more widely-visible, but that's not the same thing as
saying it's not important at all. Careful control of implementation
details vs exposed API even within a single file is still useful, either
because it's much easier to make the type public if desired, or because
it makes any future refactoring much easier. And it also helps you to
reason about the code as you're looking at it, because when you're
looking at a private declaration, you only have to consider the
immediate enclosing scope, as opposed to a fileprivate declaration where
you have to consider the whole file.

-Kevin Ballard

>  On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>  <daniel at duan.org> wrote:
>>
>> You might as well ask "why not make everything public" if private and
>> fileprivate makes no difference to you.
>
> That is not a fair assertion at all. The API which a type vends to
> other files within its module, and to clients outside its module, are
> significant parts of a quality and maintainable design.
>
> I do not think the API which a type vends *within its own file*
> warrants such lofty prioritization.
>
>
>> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>> <daniel at duan.org> wrote:
>>>
>>>
>>> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky
>>> <nevin.brackettrozinsky at gmail.com> wrote:
>>>
>>> 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.
>
> You can’t just write off the complexity cost like that. The new scope-
> based “private” access level brings *substantial* complexity, to both
> the implementation and the mental programming model. It creates
> *unutterable* access levels, where a scope can see a member of another
> scope, but cannot create its own member with the same access level.
>
>
>> On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan
>> <daniel at duan.org> wrote:
>>
>>
>> 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.
>
> Right, “unwieldy” is not enough to justify a source-breaking change. I
> entirely agree.
>
> It is the *complexity* of the current model that would justify the source-
> breaking change, if it does not have real benefits which stand on
> their own and outweigh the costs.
>
> What unwieldiness *does* justify is a non-breaking change, such as
> introducing “privy” (or something else) as a synonym for
> “fileprivate”, then eventually deprecating and removing the latter.
>
> • • •
>
> I will also note that the principal practical effect of SE-0025 was
> “Replace a small number of occurrences of ‘private’ with
> ‘fileprivate’.”
>
> That is essentially all it did to source code. It brought a
> significant increase to the complexity of the access control model, in
> order to make a few member declarations lengthier and more awkward.
>
> Maybe there are other benefits, but I have not seen them.
>
> • • •
>
> Let me reiterate my stance: if the new scope-based “private” has
> benefits which outweigh its complexity cost, then we should keep it.
> Otherwise we should get rid of scope-based access control and
> reinstate the old file-based “private”.
>
> Furthermore, we should rename “fileprivate” to something shorter and
> less awkward, which will play nice with submodules. If “private” is
> off the table then I propose “privy”, though I welcome other
> suggestions.
>
>  Nevin
>
>>> 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 at 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 at swift.org> wrote:
>>>>>
>>>>>> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution <swift-
>>>>>> evolution at swift.org> wrote:
>>>>>>
>>>>>>
>>>>>>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution <swift-
>>>>>>> evolution at swift.org> a écrit :
>>>>>>>
>>>>>>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution <swift-
>>>>>>> evolution at 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 at 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 at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>>  swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
> _________________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161019/5e11bf72/attachment.html>