A quick note, I'm not sure if it's a hack but you can probably still do this:<div><br></div><div> guard let `self` = self else { return }<br><br>It would be good to support this without backticks, I suppose it would be very special case though. I wonder if you could reassign self as a different type...<br><br><br>Andrew Bennett</div><div><br>On Saturday, 20 February 2016, Kurt Werle via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 19, 2016 at 3:12 PM, Shawn Erickson <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','shawnce@gmail.com');" target="_blank">shawnce@gmail.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="ltr">Kurt curious... the "[unowed self]? in" style... is that part of another proposal? The one I hit on is talking about using "[guard self] in".</div></blockquote><div><br></div><div>Kenny Leung originally suggested instead of [guard self] (or my earlier notion of [firm self]) that it be [unowned/weak self]? - which more closely resembles the intent of object?.method() in that it does exactly the same kind of thing - whereas [guard self] implies guard, which implies an else statement and more complexity.</div><div><br></div><div>The drawback - as you have pointed out - is what to do with multiple parameters</div><div>[unowned self, some, others]? </div><div>What does that do? My (Kenny's) notion is that it implicitly does</div><div>if let self = self, some = some, others = others {</div><div> ...</div><div>}</div><div> </div><div>What if you want some tricky combination of strong/weak references in that block that you want to handle, where some may be nil and others not? Yeah, this would not work for that. But I can count the number of times where I wanted complex references in a [parameter block] where I did not have to handle them with various guards/if let's using no hands. Which is to say, this proposal is specifically for the very common boiler plate where you want everything not to be nil, you don't want to explicitly unwrap it with boiler plate code, and you want nothing to happen if something is nil.</div><div><br></div><div>While I like the look of [unowned self]? better than [guard self], I'd be happy enough with either.</div><div><br></div><div>Kurt</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 3:08 PM Shawn Erickson <<a href="javascript:_e(%7B%7D,'cvml','shawnce@gmail.com');" target="_blank">shawnce@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am talking about when capturing weak. The unowned capture situation is the simpler variant of weak, one that doesn't happen to exhibit the gyration of strongifying a weak capture.<div><br></div><div>In the weak situation you most often want to promote the captured weak reference to a strong reference for some scope of code. You have to do this currently by assigning the one or more captured weak references you have to a differently named strong reference.</div><div><br></div><div>Additionally it isn't clear to me how a block with multiple captures would play in what you are proposing.</div><div><br></div><div>If the strongify situation could be improved by allowing a captured weak reference to be made strong while avoiding the renaming gyration then I could see that being coupled with the "[weak/unowned foo]? in" no-op case (assuming folks see enough reason for the no-op case).</div></div><div dir="ltr"><div><br></div><div>-Shawn</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 2:47 PM Kurt Werle <<a href="javascript:_e(%7B%7D,'cvml','kurt@circlew.org');" target="_blank">kurt@circlew.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">And to follow up on my own email, isn't that exactly the flow you want?<div><br></div><div>First you do</div><div>{ [unowned self]? in </div><div> ...</div><div>}</div><div><br></div><div>Then you realize that you need to deal with the else case. You nuke the ? and add a guard.</div><div>{ [unowned self] in</div><div> guard if unowned self != nil self {</div><div> ...</div><div><br></div><div>I mean -- I look at that and it seems clear and easy. You have the ? to deal with the nil case. You remove it and add the block to deal with the special nil case. The intention of both seems clear. You added the guard code when you needed it.</div><div><br></div><div>Sign me up!</div><div>Kurt<br><div class="gmail_extra"></div></div></div><div dir="ltr"><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 19, 2016 at 2:39 PM, Kurt Werle <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','kurt@circlew.org');" target="_blank">kurt@circlew.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Feb 19, 2016 at 2:30 PM, Shawn Erickson <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','shawnce@gmail.com');" target="_blank">shawnce@gmail.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="ltr">I get that :) but I think it would be helpful to go beyond the no-op case and help solve the "strongify" situation that exists in the larger problem domain.<div></div></div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>OK - so what's wrong with:</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>{ [unowned self] in</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> guard self != nil else {</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> Do the other thing</div><div> }</div><div>}</div></div><div></div></div></div></blockquote></div></div></div></blockquote><div><br></div></span><div>It's basically what you're asking for - an unowned implicitly unwrapped variable followed by an else statement that takes care of the nil case. Right?</div><span><font color="#888888"><div><br></div><div>Kurt</div><div>-- <br></div></font></span></div><span><font color="#888888"><div>kurt@CircleW.org<br><a href="http://www.CircleW.org/kurt/" target="_blank">http://www.CircleW.org/kurt/</a><br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div></div><div dir="ltr"><div><div class="gmail_extra">-- <br><div>kurt@CircleW.org<br><a href="http://www.CircleW.org/kurt/" target="_blank">http://www.CircleW.org/kurt/</a><br></div>
</div></div></div></blockquote></div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>kurt@CircleW.org<br><a href="http://www.CircleW.org/kurt/" target="_blank">http://www.CircleW.org/kurt/</a><br></div>
</div></div>
</blockquote></div>