[swift-evolution] [Pitch] Allow nested protocol declarations
David Sweeris
davesweeris at mac.com
Thu Apr 28 17:09:19 CDT 2016
In your example, other types would still be able to conform to Delegate, by referencing it as "MyController.Delegate”, right? If so, I’m +1.
I’d imagine that it might also simplify the compiler a bit if we got rid of restrictions on where nested types are allowed to be declared.
- Dave Sweeris
> On Apr 28, 2016, at 12:15 PM, Brad Hilton via swift-evolution <swift-evolution at swift.org> wrote:
>
> Type nesting allows some convenient and straightforward semantics that we see inside the Swift standard library such as views on String like String.CharacterView, String.UnicodeScalarView, etc. However a protocol cannot be nested in a type and gives a non-obvious error that the “Declaration is only valid at file scope.” Just as other nested types allow proper contextual scoping, a nested protocol could make a lot sense for a number of patterns. For example, there are many “Delegate” protocols throughout the Cocoa frameworks. Here’s a controller/delegate pattern before and after type nesting:
>
> // Without type nesting
>
> protocol MyControllerDelegate : class {
>
> }
>
> class MyController {
>
> weak var delegate: MyControllerDelegate?
>
> }
>
> // With type nesting
>
> class MyController {
>
> weak var delegate: Delegate?
>
> protocol Delegate : class {
>
> }
>
> }
>
> Though the change is mostly semantics, it does allow an explicit association between My Controller and the Delegate instead of only a named association. It also cleans up the module name space like other nested types and makes associated protocols more discoverable in my opinion.
>
> I’d love to hear everyone’s thoughts.
>
> Brad Hilton
> _______________________________________________
> 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/20160428/50c0eda7/attachment.html>
More information about the swift-evolution
mailing list