<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
