This can be achieved without control flow modification already.

file, err := os.Open(path)
if err != nil {
    return err
}

var closeOnce sync.Once
defer closeOnce.Do(func() { file.Close() })

// use file here
closeOnce.Do(func() { file.Close() })

// do other stuff.

@tkw1536 certainly that's another approach that currently works.

The aim of this proposal is to make doing the right thing so simple, straightforward and lightweight that everybody does it by default, and we can even add lints which use rules of thumb to push people in the right direction.

The fact that the pattern you suggest isn't used in a very high percentage of defers today is evidence we could do with something better here.

It should be noted that today you can also use anonymous functions for this. (Admittedly it can be a little awkward with return values, but at least you don't have to define a totally separate helper function.)

func foo(path) error {
    err := func() error {
        file, err := os.Open(path)
        if err != nil {
            return err
        }
        defer file.Close()
       // use file here
    }()
    if err != nil {
        return err
    }

    // more stuff here
}

That said, I can definitely sympathize with the desire for a more convenient syntax. However, one thing to note about this proposal is it will lead to a lot of nesting in case there are several defers.

f1, err := os.Open(...)
if err != nil { ... }
defer f1.Close() {
    f2, err := os.Open(...)
    if err != nil { ... }
    defer f2.Close() {
        ...
    }
}

Also this specific proposal introduces a potential ambiguity in the grammar. The following could either be a normal defer statement followed by a block (as is the case today), or a scoped defer statement (your proposal). You could argue that it is clearly the former (to align with how if is handled), but that seems like a common source of mistakes if developers are not careful.

defer f1.Close()
{
    ...
}

Not a super fan of requiring a dedicated block to scope the defer (to see why imagine you need to have N files open: it's going to quickly start drifting right).

file1, err := os.Open(path1)
if err != nil {
    return err
}
defer file1.Close() {
	  file2, err := os.Open(path2)
	  if err != nil {
	      return err
	  }
	  defer file2.Close() { 
			file3, err := os.Open(path3)
		    if err != nil {
		        return err
		    }
		    defer file3.Close() {
			    // potentially more levels...
			    // use files here
			}
	  }
}

// do other stuff.

Also, it would force all variables in the defer scope to become inaccessible outside the scope, and this would manifest in a weird asymmetry: e.g. in the example above in // do other stuff you would still be able to access the (closed) file1, but not file2 or file3 (unless, obviously, you define them before entering the first defer scope, and then you don't shadow them by mistake).

Not advocating for a specific alternative, but a shorthand syntax that just allowed users to trigger the execution of a defer immediately (and not executing it when the function returns) would be more desirable (that is basically what the sync.Once approach is). Bonus points from me if the new syntax allowed also a future extension to disarm a defer.

@rittneje @CAFxX thanks for your points. All sensible!

Firstly, I think they don't necessarily kill the proposal.

I don't believe the ambiguity point is correct. This is currently illegal:

if true
{
   // Do something
}

syntax error: unexpected newline, expecting { after if clause

And similarly it would be required for the block to begin on the same line as the defer statement. It might be worth having a linter check for a defer followed by a scope on the next line if it ends up being a common pitfall, but I doubt that.

I think the majority of cases don't have nesting defers, so I'm ok having heavily indented files when they do occur (or using an alternative option in such cases). Similarly, based on my experience with C#'s using, in most cases you don't need a variable to escape the block scope, and when you do it's not too difficult to declare the variable up front, much as people do for if and for statements today.

I agree it is unfortunate that the file would still be in scope after the block exits, but that is something a linter should be able to detect in most situations.

That said I have some alternatives, which if people are interested in I'm happy to open proposals for.

alternative 1 - add scoped defer statement

We add a contextual keyword scoped. A scoped defer runs whenever the surrounding block (implicit or explicit) exits.

This allows doing this:

// Introduce a new block here for purpose of scoping file.
{
  file, err := os.Open(path)
  if err != nil {
    return err
  }
  scoped defer file.Close() 
  // use file here

  // defer statement runs here when scope exits
}
// do other stuff.

alternative 2 - defer statements return an instance of the Deffered interface.

We define an interface Deffered:

type Deffered interface {
  Run()
  Cancel()
}

defer returns an instance of this interface.

This would allow explicitly running the deferred statement early or cancelling it as follows:

file, err := os.Open(path)
if err != nil {
    return err
}
closeFile := defer file.Close()
// use file here
closeFile.Run()
// do other stuff.

If Run() is called the defer statement will not execute when the function exits.

The big disadvantage of this approach is that if the user breaks or continues out of the scope before calling Run the defer statement won't be executed till the function exits.

related (dup?) of #38520 #30130

To fix the nesting, how about the ability to specify a label for a defer, then use the label to specify a scope? In other words, something like

func Example() err {
files:
  {
    file1, err := os.Open(path1)
    if err != nil {
      return err
    }
    defer files, file1.Close()

    file2, err := os.Open(path2)
    if err != nil {
      return err
    }
    defer files, file2.Close()

    // Do stuff with files.
  } // Deferred stuff runs here or when control flow otherwise leaves the labeled block.

  // The defers above have both run by this point.
}

I don't know if I like this idea in general, but I do like @DeedleFake 's suggestion quite a bit more than the original proposal on this issue.

I'm not 100% sure but I don't think we need the comma.

I'm not 100% sure but I don't think we need the comma.

I didn't have the comma originally, but it felt inconsistent with a multi-argument return. This is a tad different, obviously, but at least at a glance the syntax is pretty similar in that it's a keyword with more than one thing being 'passed' to it.

I'm fine with the label approach, but I would really prefer if there was a way to refer to the current scope without a label (as i would expect the current scope to be the most commonly used, as is the case for break and continue).

Just to clarify: I'm obviously not suggesting to change the current defer behavior

As discussed above, there are already ways to scope a defer statement, such as by wrapping it in a function literal. The syntax suggestions here, while sometimes convenient, aren't enough of an improvement to justify adding additional syntax to the language.

Therefore, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.