> On Mar 21, 2017, at 10:02 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > >> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka <cocoa...@charlessoft.com >> <mailto:cocoa...@charlessoft.com>> wrote: >> >>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu <xiaodi...@gmail.com >>> <mailto:xiaodi...@gmail.com>> wrote: >>> >>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka <cocoa...@charlessoft.com >>> <mailto:cocoa...@charlessoft.com>> wrote: >>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu <xiaodi...@gmail.com >>>> <mailto:xiaodi...@gmail.com>> wrote: >>> >>>> >>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka <cocoa...@charlessoft.com >>>> <mailto:cocoa...@charlessoft.com>> wrote: >>>>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@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? > > 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. > > Isn't supporting the following part and parcel of encapsulation? > > ``` > class Foo { > private var a: Int { return 42 } > } > > class Bar : Foo { > private var a: Int { return 43 } > var b: Int { return a } > } > > print(Bar().b) // 43 > ``` > > Tight compiler-verified encapsulation would, AFAIK, require that the same > thing work with types and extensions. As I said above in my reply to Drew, > it's an inconsistent argument to say on the one hand that `private` is a > powerful feature with many uses, and then when the general principles are > applied in a logical manner to reveal certain use cases, to disown specific > uses because they're hard to reason through or difficult to implement. We > didn't want those anyway. Yes, yes we did.
Nobody is saying it shouldn’t work the way you state it should. Yes, it should work that way. Yes, it is a bug in the compiler. That does not mean this resembles the real world use cases we have for this feature. Pointing this out is not “disowning” these other uses. I don’t find these examples hard to reason through at all. It is quite clear what the correct behavior is. That doesn’t mean these are examples of good code. There are all kinds of ways to abuse most features in a programming language and this one is no exception. The encapsulation we’re looking for here is not encapsulation for the purpose of avoiding naming conflicts. Avoiding those is trivial at this level of granularity. The encapsulation we’re looking for, and have stated repeatedly, is compiler-verified encapsulation of invariants of one kind or another. > > 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 >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
