[swift-evolution] private & fileprivate

Fri Oct 14 16:54:07 CDT 2016

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.

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

 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161014/5a10a928/attachment.html>