> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu <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. > —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 https://lists.swift.org/mailman/listinfo/swift-evolution
