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.
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…
Sent from my iPad
> On Jun 19, 2017, at 6:51 PM, Michael Ilseman <milse...@apple.com> wrote:
>
>
>> On Jun 19, 2017, at 11:47 AM, Michael Savich <savichmich...@icloud.com>
>> wrote:
>>
>> 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.
>
> I was referring to defining a local function inside your function that you’re
> refactoring. As in, rather than say:
>
> func foo(...) -> … {
> // some initialization
> do {
> … some local variables, some not local...
> }
>
> code1...
>
> // some more scoped work
> do {
> … some local variables, some not local...
> }
>
> code2...
>
> // some finalization
> do {
> … some local variables, some not local...
> }
> }
>
> You have:
>
> func foo(…) -> … {
> func doLocalSetup(…inputs...) {
> … use explicit inputs and local variables
> }
> func performScopedWork(…inputs…) {
> … use explicit inputs and local variables
> }
> func doFinalTearDown(…inputs…) {
> … use explicit inputs and local variables
> }
>
> doLocalSetup(…)
> defer { doFinalTearDown(…) }
>
> code1...
>
> performScopedWork(…)
>
> code2...
> }
>
>
> 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.
>
>> 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.
>>
>
> 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.
>
>> Anyway, do you think that most Swift users are even aware that do can be
>> used in this fashion?
>>
>
> 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.
>
> 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.
>
>> Sent from my iPad
>>
>>> On Jun 19, 2017, at 2:33 PM, Michael Ilseman <milse...@apple.com> wrote:
>>>
>>> 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.
>>>
>>>
>>>> On Jun 18, 2017, at 7:07 PM, Michael Savich via swift-users
>>>> <swift-users@swift.org> wrote:
>>>>
>>>> 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.
>>>>
>>>> I'm wondering, why not 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.
>>>>
>>>> Yes I could adopt a functional style of programming, but that has its
>>>> downsides too, namely reading any functional code involves t
