[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu]

On Tue, Mar 21, 2017 at 9:15 PM, Drew Crawford via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
>
> On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution (
> swift-evolution at swift.org) wrote:
>
> Swift should only impose a preference when it's important to the speed,
> functionality, and safety of the language. I have yet to be convinced that
> there's a benefit to a scoped access level that fits anywhere in there.
>
> SE-0025 addresses these *specific* points.
>
> speed & safety:
>
> > Also, there is a greater danger of using private APIs if they do
> something similar to public APIs but are somehow more optimized (because
> they make additional assumptions about the internal state).
>
> functionality:
>
> > It forces a one class per file structure, which is very limiting.
> Putting related APIs and/or related implementations in the same file helps
> ensure consistency and reduces the time to find a particular API or
> implementation. This does not mean that the classes in the same file need
> to share otherwise hidden APIs, but there is no way to express such
> sharability with the current access levels.
>
>
>
>
> I have spent entire weeks of class trying to extoll the benefits, so
> breathlessly shared on these mailing lists, of how beautiful it is to have
> a scoped access level. I have yet to succeed.
>
> Perhaps this suggests scoped access modifiers are more comparable to e.g.
> “owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107.
> Those features are breathtakingly difficult to teach, with design documents
> in the dozens of pages that are so dense I do not understand them.
>
> However, they solve hairy problems down in the dungeon somewhere, and most
> programmers do not actually need to know them to write their code.
>
> I don’t think scoped is quite to that level, but even if it were: if you
> like your visibility modifiers you can keep them!  There is no law that
> says you must use all the modifiers,
>
No, but you must understand what all of them mean to reason about code. You
can read and write a lot of useful Swift without understanding raw
pointers. You cannot reason about Swift code very well if you do not
understand access modifiers, especially `private`. If you're arguing that
new `private` is necessary to solve "hairy problems down in the dungeon
somewhere," it should certainly not be the so-called "soft" default that
comes with being named `private`. That is the diametrical opposite of how
it was pitched in SE-0025, where it's expected to be the overwhelmingly
most common choice.

And again, interoperability with C is a tentpole feature of Swift, so the
balance is different. Swift makes no such promises about encapsulation
within a module; in fact, IIUC it's a non-goal. So the balance between
power and teachability is distinctly different.

> and the availability of a feature does not “impose on all of us the
> personal code style preferences” of anyone.  Removing a feature does, and
> that’s the present proposal.
>
> _______________________________________________
> 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/20170321/254f24d7/attachment.html>