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, 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
