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

[Xiaodi Wu]

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

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
> 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?
>
>
> Because there are other uses cases for ‘private', *not* involving
> extensions, which I *do* care about. The fact that part of the proposal was
> badly written (and really, that’s all this is
>

Huh? The code above *should compile*--that is a primary aim for SE-0025. It
does not compile and there is not a timeline (afaict) for its compiling. It
does not bother you that the 25th proposal considered in the Swift
evolution process, already once revised, is not fully implemented and may
never be?

—it uses “class or extension” as a synonym for “any type declaration" when
> really, it makes just as much sense for structs to have private members as
> classes. Stuff happens!) does not invalidate the other use cases. And yes,
> I’m aware that my coding style may differ from other people, who may use
> the language in a different way. We shouldn’t break *their* use cases,
> either.
>

We shouldn't break their use cases _without good reason_, but we shouldn't
hesitate to break their use cases if (a) there is an extremely justifiable
reason for it; and (b) the migration path is straightforward; and
(preferably) also (c) the breakage is relatively uncommon. I happen to
think those criteria are met for the reasons I've outlined extensively
above, and you may certainly quibble with that conclusion--but saying that
we shouldn't break anyone's use case, period, is not at all reasonable.

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?
>
>
> No one has. That’s the point!
>
> Charles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/8f62da92/attachment.html>