<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 3:35 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br>Sent from my iPad</div><span class=""><div><br>On Feb 22, 2017, at 5:28 PM, David Hedbor <<a href="mailto:neotron@gmail.com" target="_blank">neotron@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 3:09 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Feb 22, 2017, at 4:57 PM, David Hedbor <<a href="mailto:neotron@gmail.com" target="_blank">neotron@gmail.com</a>> wrote:</div><br class="m_-4892493040466955419m_7367089202577835215Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 2:23 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="m_-4892493040466955419m_7367089202577835215gmail-"><blockquote type="cite"><div>On Feb 22, 2017, at 4:06 PM, David Hedbor <<a href="mailto:neotron@gmail.com" target="_blank">neotron@gmail.com</a>> wrote:</div><br class="m_-4892493040466955419m_7367089202577835215gmail-m_385992422699934600Apple-interchange-newline"><div><div dir="ltr">One more thing I'd like to add into the discussion is handling of optional variables. My assumption is that if I have an optional variable in the outer scope, it would remain optional in the inner scope, but the way the draft is worded, it might seem like it would add an implicit guard statement in that situation. i.e:<div><br></div><div> var opt: Bool?</div><div> var closure = ?{</div><div> if opt {} </div><div> }</div><div><br></div><div>=></div><div><br></div><div><div> var opt: Bool?</div><div> var closure = { </div><div> guard let opt = opt else { return }</div><div> if opt {} </div><div> }</div></div><div><br></div><div>What are your thoughts on this?</div></div></div></blockquote><div><br></div></span><div>This is a great question! </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>In this example guarded closures make no difference at all because `Bool?` is a value type so it is not captured by reference.</div></div></div></blockquote><div><br></div><div>Indeed, using Bool here was a bad choice for my example.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>If it was an optional reference type the guard would fire as soon as the value was `nil` which would be immediately if the value was already `nil` when the closure was created. This is the same behavior you would get today by writing it out manually.</div></div></div></blockquote><div><br></div><div><br></div><div><div class="gmail_extra">I.e unless otherwise overridden with a [weak opt] or similar statement, this ?{} syntax would also enforce non-nil status of any passed in reference types. </div><div class="gmail_extra"><br></div><div class="gmail_extra">This could by itself be a very useful shortcut, but should probably be called out explicitly in the proposal just to remove any possible confusion of intent. As per my original question, it's most certainly obvious how this would be handled. I'm also not sure if this is usually the most desirable outcome.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think it would be more logical as a developer if your optionals remain optional within the block, but with the difference that they aren't strongly captured, and as such might become nil by the time the block executes, even if they weren't at the time of creation. Removing the optionality might force a lot of [weak param] statements that otherwise wouldn't be needed. </div></div></div></div></div></div></blockquote><div><br></div></span><div>The intent is to make this behave exactly as if you had written it out manually and had guarded all captured references. I think it works when it changes the default. It would be confusing to add special cases for things that are already optional. If you don’t want guarded behavior you’ll just need to use the capture list as you showed.</div></div></div></blockquote><div><br></div><div><br></div><div>Ok, I can buy that. Still feel like this should be explicitly called out. It's literally equivalent to [weak X] + guard let x = x { else return } for each and every captured reference, unless otherwise overridden in the capture list.</div></div></div></div></div></blockquote><div><br></div></span><div>The proposal does demonstrate this but I'll give it another look. It sounds like it's not as clear as it could be.</div><div><div class="h5"><br></div></div></div></blockquote><div><br></div><div><br></div><div>Indeed it does, but with a non-optional reference. It's entirely plausible that it's obvious to most, and that I'm overthinking it. Still doesn't hurt to add a few lines specifically addressing it I think. </div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="h5"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="m_-4892493040466955419h5"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="m_-4892493040466955419m_7367089202577835215gmail-h5"><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>David</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 1:40 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Feb 22, 2017, at 3:36 PM, David Hedbor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4892493040466955419m_7367089202577835215gmail-m_385992422699934600m_2520753025250174004Apple-interchange-newline"><div><div dir="ltr">I did read it, but I think I skimmed it a bit too fast. You're correct in that it essentially solves the same problem using a different syntax (more compact at that). I think when I initially read it, I parsed it as the method would return at any point if the objects were freed (mid-execution of the closure). Re-reading it, I see that the proposal is in fact identical in functionality to mine, just with a different syntax. <div><br></div><div>Given that your proposal still allows for overriding the behavior on an individual basis, the same thing can be accomplished. I'll put my support behind your draft, rather than expending more time with mine. :)</div></div></div></blockquote><div><br></div></span>Thanks David, glad to hear it! </div><div><div class="m_-4892493040466955419m_7367089202577835215gmail-m_385992422699934600h5"><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Cheers, </div><div><br></div><div>David</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 12:57 PM, Matthew Johnson <span dir="ltr"><<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Hi David,<div><br></div><div>I just shared a draft proposal to introduce guarded closures last week: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/Week<wbr>-of-Mon-20170213/032478.html</a>. I think you would find it very interesting.</div><div><br></div><div>I considered including a new capture list specifier `guard` in this proposal but decided against it. Guarded behavior requires prefixing the contents of the closure with a guard clause that returns immediately if the guard is tripped. This is a property of the closure as a whole, not of an individual capture. For that reason, I decided that allowing a `guard` specifier for an individual capture would be inappropriate. </div><div><br></div><div>Instead, a guarded closure has a guarded by default capture behavior which can be overridden with `weak`, `unowned` or `strong` in the capture list. The thread on this proposal was relatively brief. I plan to open a PR soon after making a few minor modifications.</div><div><br></div><div>Matthew</div><div><br><div><blockquote type="cite"><div><div class="m_-4892493040466955419m_7367089202577835215gmail-m_385992422699934600m_2520753025250174004h5"><div>On Feb 22, 2017, at 2:48 PM, David Hedbor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-4892493040466955419m_7367089202577835215gmail-m_385992422699934600m_2520753025250174004m_6478817709710489288Apple-interchange-newline"></div></div><div><div><div class="m_-4892493040466955419m_7367089202577835215gmail-m_385992422699934600m_2520753025250174004h5"><div dir="ltr"><span style="font-size:12.8px">Hello,</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">(apologies if this got sent twice - gmail and Apple mail seems to confused as to what account the first mail was sent from)</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">I’m new to this mailing list, but have read some archived messages, and felt that this would be a reasonable subject to discuss. It’s somewhat related to the recent posts about @selfsafae/@guarded but distinctly different regardless.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Problem:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">It’s often desirable not to capture self in closures, but the syntax for doing so adds significant boilerplate code for [weak self] or us unsafe when used with [unowned self]. Typically you’d do something like this:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px"> { [weak self] in self?.execute() }</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">This is simple enough but often doesn’t work:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">{ [weak self] in self?.boolean = self?.calculateBoolean() ]</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">This fails because boolean is not an optional. This in turn leads to code like this:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">{ [weak self] in</span><br style="font-size:12.8px"><span style="font-size:12.8px"> guard let strongSelf = self else { return }</span><br style="font-size:12.8px"><span style="font-size:12.8px"> strongSelf.boolean = self.calculateBoolean() }</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">And this is the boilerplate code. My suggestion is to add a syntax that works the same as the third syntax, yet doesn’t require the boilerplate code.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Solution:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Instead of using unowned or weak, let’s use guard/guarded syntax:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">{ [guard self] in</span><br style="font-size:12.8px"><span style="font-size:12.8px"> self.isExecuted = self.</span><span style="font-size:12.8px">onlyIfWeakSelfWasCaptured<wbr>()</span><br style="font-size:12.8px"><span style="font-size:12.8px">}</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">In essence, guarded self is equivalent to a weak self, that’s captured when the closure is executed. If it was already released at that point, the closure is simply not executed. It’s equivalent to:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">{ [weak self] in</span><br style="font-size:12.8px"><span style="font-size:12.8px"> guard let strongSelf = self else { return }</span><br style="font-size:12.8px"><span style="font-size:12.8px"> strongSelf.isExecuted = strongSelf.</span><span style="font-size:12.8px">onlyIfWeakSelfWasCa<wbr>ptured()</span><br style="font-size:12.8px"><span style="font-size:12.8px">}</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Except with a lot less boilerplate code, while not losing any clarify in what it does.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Impact / compatibility:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">This is simply additive syntax, and wouldn’t affect any existing code.</span><br></div></div></div>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div>