> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka <[email protected] > <mailto:[email protected]>> wrote: > >> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka <[email protected] >> <mailto:[email protected]>> wrote: >>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu <[email protected] >>> <mailto:[email protected]>> wrote: >> >>> >>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka <[email protected] >>> <mailto:[email protected]>> wrote: >>>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution >>>> <[email protected] <mailto:[email protected]>> 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?
The reason nobody cares much is because this is a degenerate case and is not actually how people want to use the feature. You don’t see people writing identically named fileprivate methods in extensions of a type in different files either. The purpose of the feature is not shadowing. That is a side effect. The purpose is to provide tight compiler-verified encapsulation. Nothing more, nothing less. >> —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 > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
