+1, would love to see UIKit's (and other frameworks') delegates/datasources nested like this one day.
It seems like there's nothing that should prevent nesting like this; it's just going to produce a different mangled name. On Thu, Apr 28, 2016 at 10:15 AM Brad Hilton via swift-evolution < swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution