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? Many people used to argue against early returns as being tantamount to > littering one’s code with GOTO statements willy-nilly, instead advocating > for assigning to a return variable which would then be returned in the last > line of the function. Swift explicitly rejects this view, offering > constructs such as the guard statement and the error-handling mechanism > which specifically encourage early returns. However, I don’t see people > using the non-acceptance of this particular argument against GOTOs as an > argument for eliminating all structured flow control from the language. > I don't follow. Which people have argued against structured control flow in Swift? And what does that have to do with rolling back a partially implemented proposal?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
