I have to agree with Michael; it seems dangerous to allow implicit capture by classes. A primary purpose (telos?) of closures is to provide this functionality, which is actually quite an advanced concept. One knows to think carefully about this when encountering a closure expression. A primary purpose of classes is to provide for encapsulation of code. Accidentally extending the lifetime of a local variable in a containing scope would be hard to notice and highly unexpected functionality. Better not to mix these things.
On Thu, Dec 22, 2016 at 17:54 Micah Hainline via swift-evolution < [email protected]> wrote: > That's exactly what I'm suggesting, the class declaration could work > similarly to a closure. > > > On Dec 22, 2016, at 4:15 PM, Michael Ilseman <[email protected]> wrote: > > > > Are you asking for a class declaration to implicitly capture and extend > the lifetime of local variables? That seems like something that’s better > done explicitly. Perhaps it’s better to think about how to reduce the > boiler plate code, e.g. better default initializers. > > > > (this is of course, additive and beyond the current scope of Swift 4 > phase 1 planning) > > > >> On Dec 22, 2016, at 2:39 PM, Micah Hainline via swift-evolution < > [email protected]> wrote: > >> > >> Currently we allow declarations of a new class in local scope, but > >> nothing can be referenced from the outer scope. Thus this is illegal: > >> > >> ``` > >> func foo() { > >> let widgetString: String = createWidgetString() > >> class SimpleProvider: WidgetStringProvider { > >> func provideWidgetString() -> String { > >> return widgetString // Illegal, defined in outer scope > >> } > >> } > >> doThingsWithWidget(provider: WidgetStringProvider()) > >> } > >> ``` > >> > >> I'm trying to feel out the edges of this decision, and figure out why > >> exactly this isn't allowed now, and how we might want to relax this in > >> the future if possible. While not a common construct, it is a useful > >> one. > >> > >> Obviously there are ways around it, very simple to create an init and > >> a private let and do something like this: > >> > >> ``` > >> func foo() { > >> let widgetString: String = createWidgetString() > >> class SimpleProvider: WidgetStringProvider { > >> private let widgetString: String > >> > >> init(widgetString: String) { > >> self.widgetString = widgetString > >> } > >> > >> func provideWidgetString() -> String { > >> return widgetString // now legal, references > >> SimpleProvider.widgetString > >> } > >> } > >> doThingsWithWidget(provider: WidgetStringProvider(widgetString: > >> widgetString)) > >> } > >> ``` > >> > >> That's boilerplate I don't want to write though, as it somewhat > >> detracts from the readability of the structure. I'm not super > >> interested in defending the concept of local class definitions itself, > >> it's already allowed in the language, I'm just interested in the > >> syntax limitation and where that line might be able to be redrawn. > >> _______________________________________________ > >> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
