On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka <[email protected]> wrote:
> > On Mar 21, 2017, at 8:15 PM, Xiaodi Wu <[email protected]> wrote: > > On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka <[email protected]> > wrote: > >> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu <[email protected]> wrote: >> >> >> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka <[email protected] >> > wrote: >> >>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution < >>> [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? > —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
