[swift-evolution] [Review] SE-0025 Scoped Access Level
natecook at gmail.com
Fri Feb 26 21:21:14 CST 2016
I support the proposed change to add a locally scoped access level. After following the original discussion and re-reading the proposal, I'm confident that this additional scope level would support the design decisions already present in Swift and help us write safer, simpler code.
Adding the local access level would essentially let extensions act as local scope blocks for a type's or protocol's methods. Many methods are made simpler by extracting an encapsulated chunk into a separate function, but these extracted bits have preconditions and requirements that would be excessive to check again.
For example, one algorithm for rotating a collection uses an "unguarded" rotate as one of its steps, which is optimized to rotate a portion of the collection without bothering to check the inputs. It makes sense to extract this bit of the full rotation algorithm into a separate function, but it's unsafe to call unless very specific requirements are met that are unlikely outside the expected context. Being able to specify a local access level for the unguarded rotation would make this safer.
While an additional access level would certainly make the system more complicated, the proposed "local" access level fits into the same framework as the three existing tiers. Unlike adding an inheritance-based level like "protected", this continues the practice of access level as defined by proximity. Types and methods are available at the global, module, or file level; this proposal would extend that down to the scope level for even finer control over the same axis of specificity.
In sum, this proposal gets my vote and I'm certain I would use the feature if added to Swift.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution