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

[Xiaodi Wu]

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

>
> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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?
>
>
> Someone finding a bug/oversight in the compiler behavior does not compel
> me to throw out the baby with the bathwater, no.
>

You're not hearing the argument. No one "accidentally" included this design
as part of SE-0025; it's sentence number one. And no one just "forgot" to
make the code above work; it simply can't be accommodated by the current
mangling scheme. And--what's more--_no one seems to be bothered by it_. If
the first sentence of a proposal can't be implemented, and no one cares
(!), is the proposal fundamentally flawed or is it just some bug?

> —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
>
>
> We’re simply going to have to disagree here.
>
> Charles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/c385fae5/attachment.html>