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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
