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

Reply via email to