Rust's Block Pattern

More significantly the new variables x and y in the block are Drop'd at the end of the block rather than at the end of the function. This can be significant if:

- Drop does something, like close a file or release a lock, or

- x and y don't have Send and/or Sync, and you have an await point in the function or are doing multi-threaded stuff

This is why you should almost always use std::sync::Mutex rather than tokio::sync::Mutex. std's Mutex isn't Sync/Send, so the compiler will complain if you hold it across an await. Usually you don't want mutex's held across an await.

Obligatory use: it’s a block I guess

Voluntary use: I know this one. It’s a pattern now.

Now that is pretty cool.

Reminds of Brian Wills OOP rant video from 2016. He advocates exactly for this pattern: https://www.youtube.com/watch?v=QM1iUe6IofM&t=2235s

I often employ this pattern in Ruby using `.tap` or a `begin` block.

It barely adds any functionality but it's useful for readability because of the same reasons in the OP.

It helps because I've been bitten by code that did this:

  setup_a = some_stuff
  setup_b = some_more_stuff
  i_think_this_is_setup = even_more_stuff
  the_thing = run_setup(setup_a, setup_b, i_think_this_is_setup)

That's all fine until later on, probably in some obscure loop, `i_think_this_is_setup` is used without you noticing.

Instead doing something like this tells the reader that it will be used again:

  i_think_this_is_setup = even_more_stuff
  
  the_thing = begin
    setup_a = some_stuff
    setup_b = some_more_stuff
    run_setup(setup_a, setup_b, i_think_this_is_setup)
  end

I now don't mentally have to keep track of what `setup_a` or `setup_b` are anymore and, since the writer made a conscious effort not to put it in the block, you will take an extra look for it in the outer scope.