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

[Xiaodi Wu]

On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka <cocoadev at charlessoft.com>
wrote:

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> So, if four/five access modifiers are too many, which one is carrying the
> least weight? Which one could be removed to simplify the scheme while
> maintaining the most expressiveness? Which one doesn't fulfill even its own
> stated goals? Well, one of the key goals of `private` was to allow members
> to be encapsulated within an extension, hidden even from the type being
> extended (and vice versa for members defined in the type). It says so in
> the first sentence of SE-0025. As seen above in my discussion with Charles
> Srstka, even supporters of `private` disagree with that motivation to begin
> with. The kicker is, _it also doesn't work_. Try, for instance:
>
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
>
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
>
> The code above should compile and does not. If I understood correctly the
> explanation from a core team member on this list, it's unclear if it can be
> made to work without changing how mangling works, which I believe impacts
> ABI and is not trivial at all. Thus, (a) even proponents of new `private`
> disagree on one of two key goals stated for new `private`; (b) that goal
> was never accomplished, and making it work is not trivial; (c) no one even
> complained about it, suggesting that it was a low-yield goal in the first
> place.
>
>
> Multiple people have already brought up cases in which they are using
> ‘private’. The repeated mention of another, unrelated use case that was
> mentioned in the SE-0025 proposal does not invalidate the real-world use
> cases which have been presented. In fact, it rather makes it appear as if
> the motivation to remove ‘private’ is based on a strange invocation of the
> appeal-to-authority fallacy, rather than an actual improvement to the
> language.
>

I'm not sure how to respond to this. SE-0025, as designed, is not fully
implemented. And as I said above, IIUC, it cannot be fully implemented
without ripping out a lot of mangling code that is unlikely to be ripped
out before Swift 4. _And there is no evidence that anyone cares about this
flaw; in fact, you are saying as much, that you do not care at all!_ If
this is not sufficient indication that the design of SE-0025 does not fit
with the overall direction of Swift, what would be?


Many people used to argue against early returns as being tantamount to
> littering one’s code with GOTO statements willy-nilly, instead advocating
> for assigning to a return variable which would then be returned in the last
> line of the function. Swift explicitly rejects this view, offering
> constructs such as the guard statement and the error-handling mechanism
> which specifically encourage early returns. However, I don’t see people
> using the non-acceptance of this particular argument against GOTOs as an
> argument for eliminating all structured flow control from the language.
>

I don't follow. Which people have argued against structured control flow in
Swift? And what does that have to do with rolling back a partially
implemented proposal?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/a8717fa1/attachment.html>