<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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.&nbsp;</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I'm wondering, why <i>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 id="AppleMailSignature"><br></div><div id="AppleMailSignature">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 id="AppleMailSignature"><br></div><div id="AppleMailSignature">So I guess what I'm saying is… somebody talk me down from this ledge. Is there a reason I <i>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 id="AppleMailSignature"><br>Sent from my iPad</div></body></html>