The using declaration refactor moves Dispose past Publish()

Highlight Publish() as a statement that now runs before disposal. Recognizing the syntax is the easy part, and it tells the editor nothing about whether this method can live with the longer lifetime.

Highlighting it is a start. It gets more interesting if Publish() is only allowed after input has been disposed. The method-scope rewrite breaks that rule, and the text change still looks completely routine.

Try one more candidate edit. Keep the original inner block and put the using declaration inside it, so disposal still happens at the end of that block. Offer it as its own option, with the affected statements visible in the preview. The choice that actually matters is which scope to keep, and a preview of deleted braces says very little about that.

Careful with what that marker promises. It can say when Dispose will run. It can't say every consumer of input has finished.

What if Read(input) keeps a reference to input somewhere that outlives the call, a field or a background task? Then the original block has the same question, refactor or not. Flag the escaping reference when the tool can see one, and keep the refactor decision about disposal scope.

Here's the version that makes the preview harder. Make input an IAsyncDisposable and the block becomes await using. Disposal is now an awaited DisposeAsync at the end of the scope, so moving the scope moves an await too. In a method that also awaits Publish(), the method-scope rewrite puts Publish() before the dispose and changes where the method yields. If the code uses ConfigureAwait(false), the dispose can also end up running on a different thread than before. None of that shows in a diff of deleted braces. The preview should say "disposal moves past these awaits", in those words.

Visual Basic never got the declaration form, so this refactor cannot even be offered there. Using input As New StreamReader(path) and End Using is the only spelling, and the scope is always written down. For someone reading the code for the first time I count that as a small kindness.

mtsuda's candidate keeps the old order. Give Dispose a line to write and Publish() another, and the three versions come apart. The original block prints read, dispose, publish. The method-scope declaration prints read, publish, dispose. mtsuda's version, the declaration inside an explicit inner block, prints read, dispose, publish again, same as the original.

So the shorter syntax and the old lifetime can live together. An extra block might help here after all, and it's the one candidate where the preview would have nothing to warn about.