<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 23, 2016, at 1:10 AM, Callionica (Swift) via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I'm certainly assuming that users have a basic understanding of scope (without that, what would be the intention behind defining the class within the function?).</div><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Despite its simplicity to you (given the example you’ve cited) this feature is quite an advanced extension to the current scoping rules.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I'm not clear on what you see as the downside of letting classes capture locals for users that are unaware of capturing.</div><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div>I’ll be blunt: This opens a gaping hole in the semantics of variable lifetimes and potentially introduces an ambiguity into resolution of the `self` keyword. For the former, consider a light extension to your original example that introduces a nested class:</div><div><br class=""></div><div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">class</span><span style="font-variant-ligatures: no-common-ligatures" class=""> Outer {</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> <span style="font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">let</span> widgetString: <span style="font-variant-ligatures: no-common-ligatures; color: rgb(112, 61, 170);" class="">String</span> = createWidgetString()</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""> <span style="color: rgb(0, 132, 0);" class="">// Initializer suppressed</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(112, 61, 170);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> foo() -> </span><span style="font-variant-ligatures: no-common-ligatures" class="">WidgetStringProvider</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> {</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(186, 45, 162);" class="">class</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> SimpleProvider: </span><span style="font-variant-ligatures: no-common-ligatures; color: rgb(112, 61, 170);" class="">WidgetStringProvider</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> {</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> // Initializer suppressed</span></div></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> provideWidgetString() -> </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">String</span><span style="font-variant-ligatures: no-common-ligatures" class=""> {</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">return</span><span style="font-variant-ligatures: no-common-ligatures" class=""> widgetString</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> }</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> }</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(112, 61, 170);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">return</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class=""> </span><span style="font-variant-ligatures: no-common-ligatures" class="">SimpleProvider</span><span style="font-variant-ligatures: no-common-ligatures; color: #000000" class="">()</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> }</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">}</span></div></div><div><br class=""></div><div>Now, from SIL’s point of view, <span style="font-family: Menlo; font-size: 11px;" class="">widgetString</span> must escape the scope it’s in and its lifetime should be extended beyond this block. Fine. But what about <span style="font-family: Menlo; font-size: 11px;" class="">Outer</span>? Because we’re returning a reference to <span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">SimpleProvider</span> which escapes the scope of <span style="font-family: Menlo; font-size: 11px;" class="">foo()</span>, and instance members of a <span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">SimpleProvider</span> capture outer context, this means we also have to keep <span style="font-family: Menlo; font-size: 11px;" class="">Outer</span> alive and around for destruction (perhaps at the point where <span style="font-family: Menlo; font-size: 11px;" class="">SimpleProvider</span> is destroyed?) </div><div><br class=""></div><div>For the latter consider trying to explicitly reference <span style="font-family: Menlo; font-size: 11px;" class="">widgetString</span> here. In <span style="font-family: Menlo; font-size: 11px;" class="">provideWidgetString() </span>we close over <span style="color: rgb(186, 45, 162); font-family: Menlo; font-size: 11px;" class="">self </span>in both <span style="font-family: Menlo; font-size: 11px;" class="">foo()</span> and <span style="font-family: Menlo; font-size: 11px;" class="">provideWidgetString()</span>. So, if I wish to make reference to <font face="Menlo" class=""><span style="font-size: 11px;" class="">Outer’s </span></font><span style="color: rgb(186, 45, 162); font-family: Menlo; font-size: 11px;" class="">self </span>explicitly, how would I go about doing it? Given that today a nested aggregate can have members with the same identifiers as their parent, how do we know if we’re capturing them or not when they’re referenced in the inner aggregate?</div><div><br class=""></div><div>~Robert Widmann</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div class="">On Thu, Dec 22, 2016 at 11:26 PM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Only if you're also assuming that people defining classes within functions would know about capturing. This violates the principle of progressive disclosure, since people naturally learn about functions and classes before they learn about closures and capturing.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Fri, Dec 23, 2016 at 01:51 Callionica (Swift) <<a href="mailto:swift-callionica@callionica.com" class="gmail_msg" target="_blank">swift-callionica@callionica.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg">Assuming capture were allowed, people defining classes within functions who didn't want them to capture could position the class definition prior to any other code in the function so that there would be nothing to capture. </div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Thu, Dec 22, 2016 at 4:13 PM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Thu, Dec 22, 2016 at 17:54 Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's exactly what I'm suggesting, the class declaration could work similarly to a closure.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">> On Dec 22, 2016, at 4:15 PM, Michael Ilseman <<a href="mailto:milseman@apple.com" class="gmail_msg" target="_blank">milseman@apple.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">> 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.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">> (this is of course, additive and beyond the current scope of Swift 4 phase 1 planning)<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> On Dec 22, 2016, at 2:39 PM, Micah Hainline via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> Currently we allow declarations of a new class in local scope, but<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> nothing can be referenced from the outer scope. Thus this is illegal:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> ```<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> func foo() {<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> let widgetString: String = createWidgetString()<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> class SimpleProvider: WidgetStringProvider {<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> func provideWidgetString() -> String {<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> return widgetString // Illegal, defined in outer scope<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> doThingsWithWidget(provider: WidgetStringProvider())<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> ```<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> I'm trying to feel out the edges of this decision, and figure out why<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> exactly this isn't allowed now, and how we might want to relax this in<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> the future if possible. While not a common construct, it is a useful<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> one.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> Obviously there are ways around it, very simple to create an init and<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> a private let and do something like this:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> ```<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> func foo() {<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> let widgetString: String = createWidgetString()<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> class SimpleProvider: WidgetStringProvider {<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> private let widgetString: String<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> init(widgetString: String) {<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> self.widgetString = widgetString<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> func provideWidgetString() -> String {<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> return widgetString // now legal, references<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> SimpleProvider.widgetString<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> doThingsWithWidget(provider: WidgetStringProvider(widgetString:<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> widgetString))<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> }<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> ```<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> That's boilerplate I don't want to write though, as it somewhat<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> detracts from the readability of the structure. I'm not super<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> interested in defending the concept of local class definitions itself,<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> it's already allowed in the language, I'm just interested in the<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> syntax limitation and where that line might be able to be redrawn.<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> _______________________________________________<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> swift-evolution mailing list<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"></blockquote></div><br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg"><br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"><br class="gmail_msg"></blockquote></div></div><br class=""><br class=""></blockquote></div><br class=""><br class=""></blockquote></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>