On Tue, Mar 21, 2017 at 9:15 PM, Drew Crawford via swift-evolution < [email protected]> wrote:
> > > > On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution ( > [email protected]) wrote: > > Swift should only impose a preference when it's important to the speed, > functionality, and safety of the language. I have yet to be convinced that > there's a benefit to a scoped access level that fits anywhere in there. > > SE-0025 addresses these *specific* points. > > speed & safety: > > > Also, there is a greater danger of using private APIs if they do > something similar to public APIs but are somehow more optimized (because > they make additional assumptions about the internal state). > > functionality: > > > It forces a one class per file structure, which is very limiting. > Putting related APIs and/or related implementations in the same file helps > ensure consistency and reduces the time to find a particular API or > implementation. This does not mean that the classes in the same file need > to share otherwise hidden APIs, but there is no way to express such > sharability with the current access levels. > > > > > I have spent entire weeks of class trying to extoll the benefits, so > breathlessly shared on these mailing lists, of how beautiful it is to have > a scoped access level. I have yet to succeed. > > Perhaps this suggests scoped access modifiers are more comparable to e.g. > “owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107. > Those features are breathtakingly difficult to teach, with design documents > in the dozens of pages that are so dense I do not understand them. > > However, they solve hairy problems down in the dungeon somewhere, and most > programmers do not actually need to know them to write their code. > > I don’t think scoped is quite to that level, but even if it were: if you > like your visibility modifiers you can keep them! There is no law that > says you must use all the modifiers, > No, but you must understand what all of them mean to reason about code. You can read and write a lot of useful Swift without understanding raw pointers. You cannot reason about Swift code very well if you do not understand access modifiers, especially `private`. If you're arguing that new `private` is necessary to solve "hairy problems down in the dungeon somewhere," it should certainly not be the so-called "soft" default that comes with being named `private`. That is the diametrical opposite of how it was pitched in SE-0025, where it's expected to be the overwhelmingly most common choice. And again, interoperability with C is a tentpole feature of Swift, so the balance is different. Swift makes no such promises about encapsulation within a module; in fact, IIUC it's a non-goal. So the balance between power and teachability is distinctly different. > and the availability of a feature does not “impose on all of us the > personal code style preferences” of anyone. Removing a feature does, and > that’s the present proposal. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
