+1 > On Apr 14, 2017, at 2:40 AM, Tino Heth via swift-evolution > <[email protected]> wrote: > > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#introduction>Introduction > > By removing the restriction that extensions can only be used as top-level > declarations, this important feature of Swift could become more powerful and > solve issues some users have with access control. > > Swift-evolution thread: Enhancing access levels without breaking changes > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035319.html> > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#motivation>Motivation > > Currently, access control is a very hot topic for Swift, and all of the > options discussed so far had strong resistance from different parts of the > community. > > This concept tries to avoid all objections that were raised against the > various modells (of course, it triggers fresh ones at the same time ;-), and > because it is purely additive, it removes the pressure to address the current > issues in Swift 4. Although it wasn't a motivation, the proposal also offers > an answer to the question if (and how) properties should be allowed in > extensions. > > SE-0169 would render major parts of this idea useless, so I think it's > qualified to be discussed in this stage. > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#proposed-solution>Proposed > solution > > Simply remove the restriction that extensions can only be declared on > top-level of a file. > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#detailed-design>Detailed > design > > There isn't much to add here: Extensions should be allowed in type > declarations and other extensions (I'm skipping methods in this draft - I see > neither big problems associated with extensions declared inside methods, nor > convincing use cases for them). > > The rules should be the same as for nested types, so marking a member of an > extension private would restrict its visiblity to the scope of this extension. > > The goals of SE-0169 could be achieved in this model by simply putting an > extension inside a type declaration, while keeping private members protected. > > Nested extensions should also be allowed to contain stored properties of the > enclosing class, thus enabling better visibility management for those as well: > > Stored properties in extensions have been requested before, but this approach > enables them quite naturally, as the rule that you can only declare stored > properties inside the declaration of a type is respected. > > It would also be possible to levearage the "default access level" feature of > extensions to group properties that should have the same visibility. > > Because there is no natural limit of nesting extensions, this feature enables > developers to design more sophisticated systems of access rights, without > increasing Swifts complexity for users that are happy with > "puplic-internal-private" and don't see the need for additional keywords or > other changes in the language. > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#future-enhancements>Future > enhancements > > For extensions of an enclosing type, that type could be easily inferred, so > some repetition could be eliminated easily. > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#source-compatibility>Source > compatibility > > Purely additive > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#effect-on-abi-stability>Effect > on ABI stability > > There are some pitfalls associated with ABI, but I don't think its stability > would be affected. > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#effect-on-api-resilience>Effect > on API resilience > > Nono known > > > > <https://github.com/tinoheth/swift-evolution/blob/NestedExtensions/0000-template.md#alternatives-considered>Alternatives > considered > > SE-0169, SE-0159, renaming "fileprivate" and/or "private" > > All of those possibilities have their own strengths and weaknesses, and there > is a huge dissent which of those are important: No matter which would be > choosen, at least one group of Swift users is punished. > > _______________________________________________ > 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
