<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Huh, I didn't realize you could nest functions like that. That being said, I'm not sure the declare-then-use structure really appeals to me personally. I might use it if the function was getting really long.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">One last question: labels on do blocks. I know they are mostly intended to be used for that goto-lite behavior, but are labels also meant to be used by themselves, to describe the code they lead into? I never understood if they were meant to be used that way in C either… <br><br>Sent from my iPad</div><div><br>On Jun 19, 2017, at 6:51 PM, Michael Ilseman <<a href="mailto:milseman@apple.com">milseman@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 19, 2017, at 11:47 AM, Michael Savich <<a href="mailto:savichmichael@icloud.com" class="">savichmichael@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Yeah, it's all about balance to be sure. Though one benefit of do blocks is in functions that are tied to a sense of time. It seems to me that the in case of something like viewDidLoad separating code into too many functions can obscure the fact that the code is meant to be executed at that time.</span></div></div></div></blockquote><div><br class=""></div><div>I was referring to defining a local function inside your function that you’re refactoring. As in, rather than say:</div><div><br class=""></div><div>func foo(...) -> … {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>// some initialization</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>do {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>… some local variables, some not local...</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>code1...</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>// some more scoped work</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>do {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>… some local variables, some not local...</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>code2...</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>// some finalization</div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>do {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>… some local variables, some not local...</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div>}</div><div><br class=""></div><div>You have:</div><div><br class=""></div><div>func foo(…) -> … {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func doLocalSetup(…inputs...) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>… use explicit inputs and local variables</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func performScopedWork(…inputs…) {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>… use explicit inputs and local variables</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func doFinalTearDown(…inputs…) {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>… use explicit inputs and local variables</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>doLocalSetup(…)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>defer { doFinalTearDown(…) }</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>code1...</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>performScopedWork(…)</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>code2...<span class="Apple-tab-span" style="white-space: pre;"> </span></div><div>}</div><div><br class=""></div><div><br class=""></div><div>That’s just one option. You also mentioned using closures, which can be less clear if you’re relying on implicit captures rather than explicit parameters (which can have labels/names). It all depends on the details.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""> Closures can provide much of the same functionality but I'm pretty sure inline closures have to have names and sometimes risking a bad name is worse than no name at all.</span></div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>That might be the case. However, often such a do block is worthy of a comment before it, and good names make really good comments.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">Anyway, do you think that most Swift users are even aware that do can be used in this fashion?<br class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>I wouldn’t think it would be obvious to new Swift programmers, but might be familiar to programmers coming from other languages that use scopes heavily. </div><div><br class=""></div><div>It probably depends on your team specifics. As you mentioned, you only recently learned of this behavior, so your experience might be a useful proxy for whether others are or are not familiar.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">Sent from my iPad</div><div class=""><br class="">On Jun 19, 2017, at 2:33 PM, Michael Ilseman <<a href="mailto:milseman@apple.com" class="">milseman@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">Introducing scope to manage lifetimes of local variables is a useful and valuable practice. Note that it might also be an opportunity to refactor the code. Any do block you want to introduce could also be a local function definition that you call later. Alternatively, it could be generalized and extracted into a utility component. Long function bodies with many do blocks could be a code smell.</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 18, 2017, at 7:07 PM, Michael Savich via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">So, something I did not know until recently is that do blocks in Swift are for more than just error handling, they can also be used to tighten scope. </div><div class=""><br class=""></div><div class="">I'm wondering, why <i class="">not</i> use a ton of do blocks? Like, if I have a ViewController lifecycle method like viewDidLoad, I could segment it into out a do block for creating subviews, a do block for loading data into them, and a do block for adding them to the view itself. This seems like it would enforce grouping code tightly together.</div><div class=""><br class=""></div><div class="">Yes I could adopt a functional style of programming, but that has its downsides too, namely reading any functional code involves trawling through a long sequence of function calls. What I'm saying is, do blocks seem like a way to get many of the benefits of functional programming while maintaining the readability of imperative code. (Sorry functional programmers, I promise I love Haskell too!)</div><div class=""><br class=""></div><div class="">So I guess what I'm saying is… somebody talk me down from this ledge. Is there a reason I <i class="">shouldn't </i>refactor my projects to be full of do blocks? And can this usage of do really be considered idiomatic Swift? Or will most people reading my code be left wondering where all the try and catch statements are?</div><div class=""><br class="">Sent from my iPad</div></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-users" class="">https://lists.swift.org/mailman/listinfo/swift-users</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></body></html>