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

[Xiaodi Wu]

On Tue, Mar 21, 2017 at 9:31 PM, Drew Crawford <drew at sealedabstract.com>
wrote:

>
>
>
> On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:
>
> You're not hearing the argument. No one "accidentally" included this
> design as part of SE-0025; it's sentence number one.
>
> To quote this in context:
>
> Scoped access level allows hiding implementation details of a class or a
> class extension at the class/extension level, instead of a file. It is a
> concise expression of the intent that a particular part of a class or
> extension definition is there only to implement a public API for other
> classes or extensions and must not be used directly anywhere outside of the
> scope of the class or the extension.
>
> I can see how an adversarial reading of the first sentence would argue
> that implementation details are not actually hidden by your example (which
> is, for the record, technically correct, the best kind of correct :-).
> However, the second sentence clarifies which kind of implementation details
> we mean to hide – the accidental use of members outside the scope.
>
These are inseparable parts of the whole. It would be absurd if I could not
have a private member in a subclass that happens to be identical to a
private member in a superclass. I can declare an internal member in an
extension to a public type that, in a different module, has an internal
member identically declared. Not being able to do so would be intolerably
broken. This goes to how essential is the encapsulation provided by
subtyping relationships, and how essential is the divide between public and
non-public members.

And this goes to my point: new `private` is enormously complicated, and now
you are trying to convince me that a certain shade of "hidden" is
sufficiently hidden. Proponents arguing for the usefulness of new `private`
show this or that use case that's enabled, but then disown the issues that
arise when the only logical interpretation of the rules leads to scenarios
that are difficult to reason about, use correctly, and (though this not
something that users would be bothered by) even support in the compiler.

> Your example does not involve hiding in that sense, so while it is
> interesting, and a bug, and should be fixed, etc., it does not thwart the
> practicable goal of the proposal.
>
> And no one just "forgot" to make the code above work; it simply can't be
> accommodated by the current mangling scheme.
>
> The Swift mangling scheme changes with some frequency, I know of around 3
> revs offhand and I do not work in that area often.  So holding this up as
> an immovable object is odd.
>
> Things would be different if we declared a stable ABI, but we did not, etc.
>
So that would be at least three revs that can't accommodate this feature. A
stable ABI may not be 4.0, but it isn't terribly far off. The window is
closing to fix the implementation, and it's not obvious that there is a
good solution.

> And--what's more--_no one seems to be bothered by it_.
>
> I volunteer to be bothered by it.  Where’s my cookie?
>
🍪 . More if you volunteer to be sufficiently bothered to fix it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/8a3109c0/attachment.html>