<div dir="ltr">Oops clicked send by mistake...<div><br></div><div>I wanted to ponder going one step farther (of course it means modifying the language a little).</div><div><br></div><div>networkRequest.fetchData() { [weak self, weak foo] result in</div><div> guard strong self else { ..., return }<br></div><div> guard strong foo else { ..., return }</div><div> ...</div><div>}</div><div><br></div><div><span><div>networkRequest.fetchData() { [weak self, weak foo] result in</div><div> if strong self {... if strong foo {...} else {...} ...} else {...}</div><div>}</div></span></div><div><br></div><div>... using strong as an attempt to imply that after the guard I want self (or foo, etc.) to be a strong reference or in the first part of the if I want self to be strong.</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 1:39 PM Shawn Erickson <<a href="mailto:shawnce@gmail.com">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 also like this proposal. I wish we could go further in removing the boilerplate but then you have to start to consider usage scenarios that you would lose in the process.<div><br></div><div>For example [guard self] capture option supports one specific situation without the ability of the block to take alternate actions in the situation of weak self being nil and also requiring no return blocks. This is great obviously for that particular situation however it doesn't really help with the other situations.</div><div><br></div><div>This proposal allows for a wide range of possibilities in a language natural way while reducing the code gyrations we currently do.</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 12:21 PM Taras Zakharko via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></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">Very much in favor of this solution (removing the standalone let self = self!). Its does not introduce any new syntax, its semantics is very obvious, its explicit, and its also much more flexible than the alternative guard capture list proposal while keeping magic to the necessary minimum. <div><br></div><div></div></div><div style="word-wrap:break-word"><div>— Taras</div></div><div style="word-wrap:break-word"><div><br><div><br><div><blockquote type="cite"><div>On 19 Feb 2016, at 20:40, Evan Maloney via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Feb 19, 2016, at 2:30 PM, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div style="margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;margin-top:0px;margin-bottom:0px;line-height:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal;word-break:normal">networkRequest<span style="color:rgb(167,29,93)">.</span>fetchData() { [<span style="color:rgb(167,29,93)">weak</span> <span style="color:rgb(167,29,93)">self</span>] result <span style="color:rgb(167,29,93)">in</span>
<span style="color:rgb(167,29,93)">guard</span> <span style="color:rgb(167,29,93)">self</span> <span style="color:rgb(167,29,93)">!=</span> <span style="color:rgb(0,134,179)">nil</span> <span style="color:rgb(167,29,93)">else</span> { <span style="color:rgb(167,29,93)">return</span> }
<span style="color:rgb(167,29,93)">let</span> <span style="color:rgb(167,29,93)">self</span> <span style="color:rgb(167,29,93)">=</span> <span style="color:rgb(167,29,93)">self</span><span style="color:rgb(167,29,93)">!</span>
</pre></div></div></div></div></blockquote><div>…isn’t there a race condition in this example (admittedly an *unlikely* one in most settings, but still…)?</div></div></div></div></blockquote></div><br><div>Yes, that's a good point.</div><div><br></div><div>Now that I think about it, allowing a standalone `let self =` could never be implemented in a way *guaranteed* to avoid a race condition, so perhaps I should remove it from the proposal altogether.</div><div><br></div><div>When I incorporate the next round of feedback, I'll rework the proposal to indicate that it can only be used with `if let` or `guard let`.</div><div><br></div></div>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div>_______________________________________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></blockquote></div>