> On Mar 21, 2017, at 10:42 PM, Xiaodi Wu <[email protected]> wrote: > > On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka <[email protected] > <mailto:[email protected]>> wrote: >> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: > >> >> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka <[email protected] >> <mailto:[email protected]>> wrote: >>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu <[email protected] >>> <mailto:[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. >> >> Or not. Here’s the actual text of the introductory paragraph: >> >> "Scoped access level allows hiding implementation details of a class or a >> class extension at the class/extension level, instead of a file. It is a >> concise expression of the intent that a particular part of a class or >> extension definition is there only to implement a public API for other >> classes or extensions and must not be used directly anywhere outside of the >> scope of the class or the extension.” >> >> So here we have “class or extension”, or some variant thereof, five separate >> times. It honestly reads like it originally just said “class”, and the >> author systematically went through it and added “or extension” to each of >> them to make sure his/her bases were covered. >> >> The meaning of that sentence is made quite clear by the example in code >> given in that proposal: >> >> ``` >> class A { >> private var counter = 0 >> >> // public API that hides the internal state >> func incrementCount() { ++counter } >> >> // hidden API, not visible outside of this lexical scope >> private func advanceCount(dx: Int) { counter += dx } >> >> // incrementTwice() is not visible here >> } >> >> extension A { >> // counter is not visible here >> // advanceCount() is not visible here >> >> // may be useful only to implement some other methods of the extension >> // hidden from anywhere else, so incrementTwice() doesn’t show up in >> // code completion outside of this extension >> private func incrementTwice() { >> incrementCount() >> incrementCount() >> } >> } >> ``` >> >> If `counter` is not visible in `extension A { ... }`, then I must be able to >> define my own `counter` in extension A. That is just how visibility works in >> Swift; no other understanding of "visibility" can be admitted here. Unless >> you mean to argue that, in reading this proposal, you honestly think it's >> correct that `counter` may or may not be declared in `extension A { ... }` >> depending on where `class A` is declared. > > Yes, the meaning *is* made quite clear. Specifically by the comments, which > explain exactly what the goal is: to make those functions not callable from > outside their respective lexical scopes. As someone else already pointed out, > the bug you found doesn’t affect the main way people use this feature, which > is why no one complains about it. > >> And didn’t quite succeed; the wording doesn’t account for value types. >> >> And anyway, I’m not sure how you even get “extensions should be able to >> shadow private members” as Priority Number One™, based on that sentence. >> Which part of the sentence does your code example violate? The sentence says >> that implementation details are hidden, and so they are. The struct can’t >> access the extension’s private members, or vice versa. The name-mangling >> issue that causes the compiler to choke is simply a *bug*, an unintended >> consequence that the author didn’t consider. And as I said before, I’d be >> perfectly fine with striking all the “or extension”s from that paragraph and >> having ‘private’ only restrict things inside the types themselves (within a >> module, of course). >> >> Whether you're fine with that is neither here nor there. It was not the >> proposal reviewed and approved by the community, and it's not the proposal >> considered here. > > Well, you’ve convinced me. Next time I find a trivial bug in the Finder, I’ll > be sure to demand that instead of just fixing the bug, Apple toss out the > whole kit and kaboodle and go back to the bash shell as the primary interface > to the file system. > > The argument is that this is _not_ a trivial issue. If Finder makes your > files disappear on a regular basis, would you not demand that Apple toss out > the whole kit?
The bug *does not affect what people use private for,* and so it *does not affect anything in real-world use.* It’s less “the Finder makes your files disappear on a regular basis” and more “if you give a file a name with a very specific sequence of Plane 2 Unicode characters, and then set the ‘Stationery' bit in the Finder flags, the icon doesn’t draw correctly.” It’s a bug, and it should be fixed, but it’s not even close to being a show-stopper. Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
