This proposal definitely needs to be more detailed, but I think I would be +1
on the idea.
---
Use cases:
1) Extending nested types
// currently possible:
extension Foo.Bar {
// must qualify some names with Foo
}
// could be possible:
extension Foo {
extension Bar {
// everything in Foo is in scope
}
}
2) Anonymous extensions
// stretch feature:
func foo() {
extension Array {
// helpers used inside function
}
}
---
Cheers,
Jaden Geller
> 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
