[swift-evolution] [Proposal] Nested extensions

[Jaden Geller]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170414/128559b6/attachment.html>