"defer" statement

[gafter]

@gafter commented on Fri Jan 22 2016

Swift recently added the defer statement. Would that make sense for C# and VB? in C# I imagine it would look something like

    {
        SomeType thing = Whatever...;
        defer {
            thing.Free();
        }
        // some code code using thing
    }

The idea is that the code in the defer block would be executed as the last action in the enclosing block. This would be the same as writing

    {
        SomeType thing = Whatever...;
        try
        {
            // some code code using thing
        }
        finally
        {
            thing.Free();
        }
    }

---

@HaloFour commented on Fri Jan 22 2016

@gafter I'd have to see use cases that aren't already sufficiently met through try/finally or using. It doesn't even seem that Apple could provide a worthwhile example of why you'd use it.

---

@alrz commented on Sat Jan 23 2016

ِDoesn't RAII (#181) address this?

{
  using Disposable thing = ...;

  // disposed
}

Because that kind of operations for a type without being a IDisposable isn't idiomatic C#.

However for this to work it should be able to borrow the object, or totally pass the ownership,

void F(Disposable d) { ... } // won't dispose as always
void G(using Disposable d) { ... } // will dispose at the end

{
  using Disposable d = ...;
  F(d); // d is borrowed
  // d is available
  G(d); // pass the ownership (move)
  // d is not available
}

This probably needs a sophisticated ownership system (then we might be able to use let instead).

Related: #160, #161.

---

@HaloFour commented on Fri Jan 22 2016

@gafter According to NSHipster the defer statement should be avoided for contexts other than ensuring resource cleanup.

I'd say that defer is Swift's answer to using and my opinion is that C# doesn't need a rebuttal or to copy a feature that can be as potentially misused/abused as this could be.

---

@DiryBoy commented on Fri Jan 22 2016

This reminds me of the defer attribute for the script tag in HTML. It allows the browser to parallel the download of the script while continue parsing html. I don't see why this is useful in C#.

---

@jamesqo commented on Sat Jan 23 2016

It's possible to just simulate this using Disposable.Create from Rx:

using (Disposable.Create(DoSomething))
{
    DoSomethingElse();
} // end of scope, DoSomething is called here

As such I don't think a defer statement is needed in C#.

---

@gafter commented on Sun Jan 24 2016

The advantages of the defer statement over the alternatives are

• They do not require implementing some interface, such as IDisposable, or creating helper objects that do.
• They do not add an indentation level to the code, which would be clumsy when there are more than one.
• They do not move the cleanup code to the end, as try-finally does, but rather they keep the cleanup code logically with the declaration and initialization of the thing that is being cleaned up. In this way they make the code easier to understand.

---

@jamesqo commented on Sun Jan 24 2016

@gafter Hm, I'm not sure. I was skeptical at first, but the arguments you presented are good.

If we're going to go down that route, we may want to consider adding an option for writing it inline like you can in Go, e.g.

var resource = AcquireResource();

defer resource.Dispose(); // no braces

---

@paulomorgado commented on Sun Jan 24 2016

Still not sold on that!

---

@HaloFour commented on Sun Jan 24 2016

@gafter

1. If IDisposable is the pattern for creating resources which should be cleaned up then I don't see much validity to this argument. Endorsing an additional pattern, or no pattern at all, would only add confusion.
2. Rx provides some fantastic helper methods which can convert any operation into a disposable. Why add language support to something that can be done easily through a library?
3. A corollary to this might be to expand using to support convention-based disposing rather than strictly requiring IDisposable, such as supporting objects that declare an instance Close() method.
4. Neither would Feature Request: allow currently mandatory, but syntactically redundant, braces to be optional #181 or a variation thereof. My personal preferred syntax would be using var disposable = new SomeDisposableObject(); Same mechanism but the resource is attached to the defining scope, no additional indentation required.
5. See point 1, this only matters if you're not using IDisposable, which you should be using anyway.

If the purpose of defer is to provide resource cleanup I'd rather find ways of improving upon using in a structured way rather than to toss in a completely new language construct with massive abuse potential which appears to have no real use cases aside resource cleanup. To toss some spaghetti against the wall, how about the following:

var resource = new MyNonDisposableResource() using resource.Close();

---

@alrz commented on Sun Jan 24 2016

@gafter I don't think that real problem with using statement is additional indentions nor that you have to implement an interface — this is not a bad thing at all, so there is a contract for types that need cleanup. I think the actual problem here is that you might forget to dispose disposable types, defer statement doesn't help with this at all, it rather encourages you to not implementat IDisposable inetrface and explicitly call methods like Close or Free which in presence of IDisposable seem like code smells.

---

@HaloFour commented on Sun Jan 24 2016

@alrz Using let as you describe seems like it would be in conflict with #6400 which is proposing that let have a completely different function. Blending the two wouldn't make much sense. And wasn't move/ownership semantics one of the tricky issues in considering #161? I'd worry that it would be too easy to lose track of true ownership, particularly if you ever call into an assembly compiled in any other language (or a previous version of C#).

---

@ufcpp commented on Sun Jan 24 2016

PowerShell has the trap statement, which has similar usage to the defer statement. The trap statement is little confusing and I prefer the try-catch statement.

---

@alrz commented on Sun Jan 24 2016

@HaloFour If we ever wanted it to be the default behavior but yes, then other languages or even earlier versions of C# might be considered as unsafe. But as I said in my first comment here, RAII (using using) does need a lightweight version of ownership, otherwise if you pass the object to another method then you're screwed. #161 and #160 are about destructible types and move keyword, but wi th an ownership system it would work for any type and there would be no need for destructible or move keywords.

---

@HaloFour commented on Sun Jan 24 2016

@alrz Changing the keywords doesn't change how difficult it may or may not be. And if developers still need to opt-into it then you still haven't solved any of the problems. At least with destructible types it was a property of the type and the consumer didn't have to opt-into anything.

RAII doesn't imply anything about ownership. The convention as it was developed in C++ relies on the lifetime of the object being tied to the stack of the method within which it was created. #181 is a much closer implementation of that than anything involving ownership, reference counting or move semantics.

---

@alrz commented on Sun Jan 24 2016

@HaloFour This is more related to #160 and #161 and somehow covering #181 but probably out of scope of this proposal, so I just give it up. 😄

---

@MgSam commented on Sun Jan 24 2016

If the the use case for defer is resource cleanup, then it would seem to be an anti-pattern to me to not require that the thing implement IDisposable. Implementing IDisposable allows tooling to warn you if you create a disposable as a local variable and then never dispose of it. If you make it accepted for resources to not require IDisposable, you lose this benefit.

I think method scoped using statements would be just as effective while being much more idiomatic.

---

@gafter commented on Sun Jan 24 2016

I see lots and lots of code like this in Roslyn:

            var oldMethodOrLambda = this.currentMethodOrLambda;
            this.currentMethodOrLambda = node.Symbol;
            ... // process the current lambda
            this.currentMethodOrLambda = oldMethodOrLambda;

I would hate to use IDisposable for this. defer would be perfect, as it keeps the "begin" and related "end" code together.

            var oldMethodOrLambda = this.currentMethodOrLambda;
            this.currentMethodOrLambda = node.Symbol;
            defer this.currentMethodOrLambda = oldMethodOrLambda;
            ... // process the current lambda

---

@leppie commented on Sun Jan 24 2016

@gafter: That is really dynamic binding. It would be nice to do syntax sugar for what I did in code here http://www.codeproject.com/Articles/153896/Dynamic-Binding-in-C

---

@GeirGrusom commented on Sun Jan 24 2016

I would like to note that D has had the scope guard statement for some time, but it allows you to do something when scope fails, or succeeds as well.

Anyway wouldn't this be more useful as a using extension? Allowing a type to determine what happens when the scope fails, succeeds and finishes (which is what using allows) could be useful.

public interface IScopeGuard
{
  void Failed(Exception  ex);
  void Success();
}

public class Transaction : IScopeGuard, IDisposable
{
  private readonly int id;
  public Transaction()
  {
    id = BeginTransaction();
    Console.WriteLine($"Started transaction {id}");
  }
  void Failed(Exception ex)
  {
    FailTransaction(id);
  }
  void Success()
  {
    CommitTransaction(id);
  }
  void Dispose()
  {
    Console.WriteLine($"Transaction {id} completed.");
  }
}

using(new Transaction())
{
   DoTransactionalStuff();
} 

edit: it occurs to me that this is a digression. Sorry about that.

---

@ghord commented on Mon Jan 25 2016

There is great talk about implementing this feature in C++ by Andrei Alexandrescu. Some string arguemnts in favor of this there.

---

@alrz commented on Mon Jan 25 2016

@gafter That use case is really similar to what Block function does in Mathematica.

block(this.currentMethodOrLambda = node.Symbol) 
{
}

Then there is no need for temporary variable and explicit defer to assign it back. If anything, I would prefer this (perhaps with another keyword) over defer because it really encourages bad design (for resource cleanup).

As an alternative I'd suggest scoped assignments,

{
  scoped this.currentMethodOrLambda = node.Symbol;
}

But it seems that this is useful only for this specific use case.

---

@MgSam commented on Mon Jan 25 2016

@gafter But that only works if there is no other logic you want to come after the restoration of this.currentMethodOrLambda. If there is, then you run the risk of the developer adding that into the defer block too, making your method into a confusing mess where the code that runs at the end is written at the top of the method body rather than the bottom. The last thing you want when you're reading code is to have to remember that there might be extra logic that takes place at the end of the method that was written out somewhere else entirely.

---

@HaloFour commented on Mon Jan 25 2016

@MgSam Agreed. For the most simple cases that may be suitable, otherwise you end up having to defer multiple operations and be extremely conscious as to the fact that they'll execute backwards lexically. This task is pretty easily accomplished through try/finally which, while more verbose, is significantly more structured and easier to follow.

var oldMethodOrLambda = this.currentMethodOrLambda;
try
{
    this.currentMethodOrLambda = node.Symbol;
    // ... process the current lambda
}
finally {
    this.currentMethodOrLambda = oldMethodOrLambda;
}

---

@paulomorgado commented on Mon Jan 25 2016

see lots and lots of code like this in Roslyn:

        var oldMethodOrLambda = this.currentMethodOrLambda;
        this.currentMethodOrLambda = node.Symbol;
        ... // process the current lambda
        this.currentMethodOrLambda = oldMethodOrLambda;

I would hate to use IDisposable for this. defer would be perfect, as it keeps the "begin" and related "end" code together.

        var oldMethodOrLambda = this.currentMethodOrLambda;
        this.currentMethodOrLambda = node.Symbol;
        defer this.currentMethodOrLambda = oldMethodOrLambda;
        ... // process the current lambda

I'm sorry @gafter, but I'm still failing to see the value of this proposal.

---

@DiryBoy commented on Mon Jan 25 2016

What is the order of multiple defer blocks, and what if exceptions throw in the middle?

---

@HaloFour commented on Tue Jan 26 2016

@DiryBoy If it were to be implemented as it is in Swift, the following C# code:

static void Main() {
    Console.WriteLine("Hello");
    defer {
        Console.WriteLine("Foo");
    }
    defer {
        Console.WriteLine("Bar");
    }
    defer {
        Console.WriteLine("Baz");
    }
    Console.WriteLine("World");
}

would produce the following output:

Hello
World
Baz
Bar
Foo

As far as I can tell it's illegal to throw from within the defer block.

---

@alrz commented on Mon Jan 25 2016

It's like a finally block in the middle of nowhere so why not reusing finally instead of defer. But when I think how messy it can get I tremble.

---

@DiryBoy commented on Mon Jan 25 2016

@HaloFour Any method call within defer block could throw. Any code could throw before defer blocks get a chance to execute. The example code is a good example of writing code backwards without any good reason.

To address the org -> current -> org property change, if to introduce language support, IMO it's better to introduce some feature that could express that one off. For example

stash this.currentMethodOrLambda = node.Symbol;
// compiler generate code to revert this.currentMethodOrLambda to it's original value on exit scope
// should exceptions happen before exit scope, the value is not reverted back

Edit: OK, duplicated with @alrz

---

@HaloFour commented on Mon Jan 25 2016

@DiryBoy

Swift is a lot stricter about exceptions than C# and doesn't permit calling functions that declare that they throw exceptions from within a defer block. As far as I can tell if a function were to fail unexpectedly, such as attempting to forcibly deference a nil, that's a fatal situation and the entire program stops. If the method throws outside of the defer blocks then those blocks are executed as expected. Not unlike wrapping the entire method body in a bunch of try/finally clauses, exception for being in reverse order. I'm certainly not an expert in Swift, though.

I'm not convinced that a temporary swap is so common as to require its own keyword and semantics. It's pretty easy to accomplish now with try/finally or one of the helpers from Rx. I'd even argue that such logic depending on changing some shared state to temporarily change how the program behaves is itself a code smell and probably shouldn't be encouraged.

---

@DiryBoy commented on Mon Jan 25 2016

@HaloFour

Thanks for sharing.

Me neither.

---

@alrz commented on Tue Jan 26 2016

@HaloFour

changing some shared state to temporarily change how the program behaves is itself a code smell

Exactly. They probably chose this pattern to avoid repeating a parameter in every function call and ended up with this.

---

@HaloFour commented on Tue Jan 26 2016

@paulomorgado Ah yeah, copypasta fail. I'll update.

---

@migueldeicaza commented on Thu Jan 28 2016

I love the idea of the defer statement in C#.

It provides an expressive way to state the programmer's desired intention. While try/finally may accomplish the same work, it pushes the intention far away, and in nested cases becomes inconvenient to navigate.

---

@GeirGrusom commented on Thu Jan 28 2016

I think defer is a very vague name though.

---

@lachbaer commented on Thu Mar 24 2016

I wouldn't recommend 'mixing' the execution order of the code with defer for the same reason that return statements should not be present in the middle of a any method or elsewhere where they could easily be overssen.

For the use-case @gafter mentioned I think it is besser to leave the assignment this.currentMethodOrLambda = oldMethodOrLambda; directly before the exit points in the method. This reminds the reader at the exit point that something is reverted to its original state.

---

@temporaryfile commented on Fri Apr 15 2016

You can mock this up with an IDisposable stack of delegates. Instead of "defer", push a lambda closure to the stack. Inside Dispose(), run them in reverse order. That's a lot of overhead for reaching a finally block that's usually less than a Page Down away. It feels pointlessly clever.

The problem with a struct implementing IDisposable to solve this pattern everywhere is that Dispose() will cause it to be boxed. We need a pattern for the using-statement, not an interface, using method names the compiler knows about, exactly like when I build awaiter/awaitable objects.

---

@svick commented on Sat Apr 16 2016

@playsomethingsaxman

The problem with a struct implementing IDisposable to solve this pattern everywhere is that Dispose() will cause it to be boxed.

No, it won't. When you you use using on a struct, the Dispose() method is called using constrained. callvirt, which does not box the value.

---

@temporaryfile commented on Sat Apr 16 2016

No, it won't. When you you use using on a struct, the Dispose() method is called using constrained. callvirt, which does not box the value.

Niiice, learn something new every day. Not sure what we really need then.

---

@gafter commented on Sat Apr 16 2016

@playsomethingsaxman

Not sure what we really need then.

I suggest you rewrite the original post using your suggested mechanism. Don't modify existing types; if you need to declare a new struct, include it in your solution. Is it easier to read?

---

@temporaryfile commented on Sun Apr 17 2016

I suggest you rewrite the original post using your suggested mechanism. Don't modify existing types; if you need to declare a new struct, include it in your solution. Is it easier to read?

I can't modify existing types but I can create extension methods? Game on. But at some point a .NET-facing library has to do its part and accommodate basic .NET patterns.

To simulate what "defer" really is...

using (var deferrals = new DeferralStack())
{
    SomeType thing = Whatever;
    deferrals.Defer(() => thing.Free());

    SomeType thing2 = Whatever;
    deferrals.Defer(() => thing2.Free());
}

To me that would be a nightmare to step through and debug, especially with GULP locks. Here's another question: what happens to the remaining deferrals if the first one throws and all of them are guaranteed to run? Do we assemble an AggregateException?

---

@gafter commented on Sun Apr 17 2016

To me that would be a nightmare to step through and debug

Yes, the alternative is pretty bad. Yet another reason to support the original proposal.

---

@whoisj commented on Sun Apr 17 2016

The defer statement is fairly novel. It's basically encouraging developers to perform RAII like operations (d'tors, etc) in immediately following code blocks instead of using scope characters (usually {). However, it also keeps state as to what bits of code get executed based on which defer statements are actually reached at run time. No more of the C clean up of if (foo) free(foo); if (bar) free(bar); or the equivalent of whatever Swift offers.

Given that it is only a compiler trick and should require no run-time support, I think this is a fantastic addition to nearly any language. Kudos to the devs at Swift for inventing it, and to the devs here on Roslyn for considering it.

Only question: what happens if a defer statement "throws"?

---

@whoisj commented on Mon Apr 18 2016

Another observation/question: does it make more sense for the sequence of defer statements to be stack or queue oriented? For example, with the following snip-it of code what should the expected outcome be?

{
    Console.WriteLine("A");
    defer { Console.WriteLine("One"); }
    Console.WriteLine("B");
    defer { Console.WriteLine("Two"); }
    Console.WriteLine("C");
    defer { Console.WriteLine("Three"); }
}

Should it be:

A
B
C
Three
Two
One

Or

A
B
C
One
Two
Three

As I understand it, with Swift's implementation the former would be the case, however the later makes more sense to me as that was the order it was declared. Thoughts?

It's like a finally block in the middle of nowhere so why not reusing finally instead of defer. But when I think how messy it can get I tremble.

I agree, but finally already has meaning and overloading the statement could cause all kinds of real errors to escape the compiler checks.

---

@HaloFour commented on Mon Apr 18 2016

@whoisj Since the prototypical use case seems to be resource cleanup I think that reverse order makes more sense. The compiler can't know if cleaning up the first resource might depend on cleaning up subsequent resources. Also, every language I've found with this facility seems to invoke in reverse order, including D, Swift, Go, Rust (via defer! macro) and C++ (via RAII, destructors are always called in reverse order).

---

@svick commented on Mon Apr 18 2016

@whoisj Just like with using and RAII, I think that stack is the only real option. Consider that the non-deferred statements could have dependencies on each other. For example, this code that uses using:

using (var fileStream = File.OpenWrite(@"C:\users\svick\desktop\test.txt"))
using (var gZipStream = new GZipStream(fileStream, CompressionMode.Compress))
using (var writer = new StreamWriter(gZipStream))
{
    writer.WriteLine("Hello World");
}

The natural way to rewrite it with defer would be:

var fileStream = File.OpenWrite(@"C:\users\svick\desktop\test.txt");
defer { fileStream.Close(); }
var gZipStream = new GZipStream(fileStream, CompressionMode.Compress);
defer { gZipStream.Close(); }
var writer = new StreamWriter(gZipStream);
defer { writer.Close(); }
writer.WriteLine("Hello World");

This would only work correctly if defers were executed in reverse order.

---

@whoisj commented on Mon Apr 18 2016

@svick good point! Explains the decision Swift made.

The using statement is fine, but it does require IDisposable which is less than optimal.

As for RAII, I'd love to see support for it. Sadly, I believe that would require more than compiler ticks to implement correctly and CLR/IL changes are pretty much out of scope.

---

@aL3891 commented on Mon Apr 18 2016

To me this sounds like a feature that would add alot of complexity and opportunity for misuse for not a lot of benefit. I assume defer would only work inside a perticular method, but resource cleanup is commonly done at a later time, say when the object itself is cleaned up. I do see the charm, but i just don't think it adds enough to the language to warrant a new keyword.

Also, what is the closure situation? Consider

for(var i = 0; i<10; i++) {
    defer Something(i);
}

Would Foobe called 10 times with 10? or 10,9,8..? i'd imagine the first, unless a local variable is declared, same as if a Func was used?

If defer statements can contain anything, they can also change state i assume, so this would be legal:

var thing = GetThing();
if(Test())
    defer thing.baz = 30
defer thing = GetOtherThing();
defer thing = null;

A bit contrived for sure, but my point is that somewhere half a page up, in some branch something is defered and that might be hard to keep track of. The execution order will jump all over the place (and i guess thats the point) but it will be hard to get an overview, i sort of have to keep stack in my head with all the deferals :)

---

@alrz commented on Tue Apr 19 2016

We might be able to do this with #6671 and code generators, marking the node we want to defer with a attribute and regenerate the syntax tree,

void Method() {
  var something = new Something();
  [[Defer]] something.Free();
  // blah
}

replace void Method() {
  var something = new Something();
  try { 
    // blah
  } finally {
    something.Free();
  }
}

However, I'm not aware if generator API allows to ReplaceNode or that kind of stuff.

---

@gafter commented on Tue Apr 19 2016

@aL3891

Also, what is the closure situation? Consider

for(var i = 0; i<10; i++) {
    defer Something(i);
}

Since defer defers until the }, and the } immediately follows, that has the same behavior as

for(var i = 0; i<10; i++) {
    Something(i);
}

Defer would not be an embedded-statement, so you could not use it as the controlled statement of an if. So no, there will be no defers hidden in branches.

---

@HaloFour commented on Tue Apr 19 2016

@gafter

I think more to the point, what would the behavior of the following be?

void Foo() {
    int i = 1;
    defer Console.WriteLine(i);
    i = 2;
}

---

@gafter commented on Tue Apr 19 2016

@HaloFour prints 2, just the same as if you wrote

void Foo() {
    int i = 1;
    try
    {
        i = 2;
    }
    finally
    {
        Console.WriteLine(i);
    }
}

(Unless you get an exception between the two assignments)

---

@aL3891 commented on Wed Apr 20 2016

Oh, it would just defer to the end of the current block? i somehow thought it deferred to the end of the entire method... :) if its just the current block i think the debugging would be much more reasonable.

---

@lachbaer commented on Tue May 03 2016

When flying over the code above, I think that it might be hard for 3rd party readers to always directly see the defer statement, esp. when the code block is more complex, has complicated algs, etc.

For a better visual experience I think that you should group the blocks where defer belongs to, e.g. using the use keyword:

void Foo() {
    use
    {
        // maybe some more statements
        var fileStream = File.OpenWrite(@"C:\users\svick\desktop\test.txt");
    }
    defer
    {
        fileStream.Close();
    }
}

or shorter:

void Foo() {
    use { 
        var fileStream = File.OpenWrite(@"C:\users\svick\desktop\test.txt"); 
    } defer { fileStream.Close(); }
}

So, the requirement would be that every defer must follow a directly preceding use block.

PS: you could use the more verbose do keyword instead of use, a lookahead behind the do-block would tell if it has a loop or a defer meaning.

PPS: adding the defer statement to the try statement additionally would then also be of use. With try exceptions can also caught by catch blocks, but in contrast to finally those blocks are always excecuted when leaving the function.

void Foo() {
    try { 
        var fileStream = File.OpenWrite(@"C:\users\svick\desktop\test.txt"); 
    }
    catch (IOException e) {
        Debugger.Log(1, "FileErrors", "Cannot open test.txt");
        return;
    }
    defer {   // outer block for defer is the Foo method
        if (fileStream != null) fileStream.Close();
    }
    // try block already ended, but fileStream is still open
    ReadFile(fileStream);
}

(I know that the sample doesn't make much sense and there are other, better ways, it's just a coding sample ;-)

---

@migueldeicaza commented on Thu May 26 2016

Another thought on defer.

The real win here is that it can be used for things that are not IDisposable. And while there was a comment earlier from @HaloFour that he sees no validity in the argument, defer is not limited to resources that must be disposed, nor is every resource or operation that requires some finalization always surface a Dispose().

Defer instead introduces a new construct that can be used not only for releasing resources, but to ensure that certain operations take place before the code completes.

@gafter already provided a common idiom from the Roslyn compiler, but this is not limited to Roslyn, the idiom "var saved = GetState (); ChangeState (newstate); DoOperation (); RestoreState (saved)" is common.

Do not take my word for it, a search here, shows very interesting uses of defer and they are not all bound to releasing resources:

https://github.com/search?l=&o=desc&q=defer+language%3ASwift&ref=advsearch&s=indexed&type=Code&utf8=%E2%9C%93

---

@HaloFour commented on Thu May 26 2016

@migueldeicaza

Quickly scanning those examples I can easily see that the vast majority of cases are Swift's reimplementations of using or lock. Surprisingly, much more the latter than the former. Of the remaining cases I mostly see bizarre ways of injecting mutation logic post return, e.g.:

  mutating func unsafePop() -> UTF8.CodeUnit {
    defer { pointer = pointer.advancedBy(1) }
    return pointer.memory
  }

I frankly don't see how that's more readable than the equivalent:

  mutating func unsafePop() -> UTF8.CodeUnit {
    let result = pointer.memory
    pointer = pointer.advanceBy(1)
    return result
  }

Sure, one less line of code, which buys you out-of-lexical-order execution of sequential statements.

I don't doubt that there are some really good novel uses for a statement like defer. I'm not seeing them in those examples. Nor do I think that the rare occasion where it might be useful warrants a language feature that is effectively an alias for try/finally. The idea of having to mentally keep track of implicit scope popping behavior when reading code does not appeal to me. Having to know when to read code backwards does not appeal to me. Encouraging people to write disposable resources that spurn the 15 year old established disposable pattern does not appeal to me.

---

@bbarry commented on Thu May 26 2016

@migueldeicaza, @HaloFour I suspect by far the most common use case for a defer statement in C# would be lock management structures like ReaderWriterLockSlim changing code like this to:

public class Set<T>
{
  private readonly HashSet<T> set = new HashSet<T>();
  private readonly ReaderWriterLockSlim readerWriterLockSlim = new ReaderWriterLockSlim();

  public bool Add(T value)
  {
    readerWriterLockSlim.EnterReadLock();
    {
      defer { readerWriterLockSlim.ExitReadLock(); }
      if(set.Contains(value))
        return false;
    }

    readerWriterLockSlim.EnterWriteLock();
    defer { readerWriterLockSlim.ExitWriteLock(); }
    return set.Add(value);
  }

  public bool Remove(T value)
  {
    readerWriterLockSlim.EnterWriteLock();
    defer { readerWriterLockSlim.ExitWriteLock(); }
    return set.Remove(value);
  }

  public T[] GetValues()
  {
    readerWriterLockSlim.EnterReadLock();
    defer { readerWriterLockSlim.ExitReadLock(); }
    return set.ToArray();
  }
}

Here, the necessary naked block in the Add method makes me more uneasy about the thought of a defer statement than anything else I've seen so far. Other tasks I'd imagine are transaction commits.

Also, how should it play with a switch statement?

void Foo(int state)
{
  int i = 1;
  {
    switch (state)
    {
      case 0: defer {i++;} goto case 1;
      case 1: defer {i *= 2;} break;
      case 2: defer {i = 3;} goto case 1;
      default: defer {i = 5;} break;
    }
  }
  Console.WriteLine(i);
}

Or yield or await?

---

@alrz commented on Thu May 26 2016

This prints a 0 b 1 because in Swift each case body has its own block.

let state = 0
switch (state) {
    case 0: defer {print("0")}; print("a"); fallthrough
    case 1: defer {print("1")}; print("b");
    case 2: defer {print("2")}; print("c");
    default: defer {print("3")}; print("d");
}

No idea how it should work in C# though.

[ghord]

How would this feature interact with goto statement?

{
    int x = 9;
label:
    defer Console.WriteLine("foo");

    if(x -- > 0)
        goto label;
}

This could write foo 10 times, but how will compiler generate the code for this? I guess mixing goto's and defer could either be disallowed.

Simillarly following block of code:

{
    if(random.Next(10) == 0)
        goto skip;

    defer Console.Writeline("foo");

    skip: ;
}

Could write either one foo or none, but again this seems problematic for the compiler.

[leppie]

@ghord Does not matter, the defer block just goes into finally, the label jumps are local to the try block which is perfectly legal for both.

It would not legal to jump across blocks like:

    int x = 9;

    defer 
    { 
      label:
      Console.WriteLine("foo");
    }

    if(x -- > 0)
        goto label; // invalid target

[ghord]

@leppie So you are basically proposing that

{
    goto skip;
    defer Console.WriteLine("foo");
    skip: ;
}

should still print to the console, even when defer statement is not reachable? This may seem a little counter-intuitive.

[lachbaer]

I think that a deferred block should only be executed, when leaving the method, when it's corresponding defer statement was reached during the methods flow. This could be achieved by wrapping the defer blocks in synthesized if statements that check for a synthesized boolean local, that is set if the defer statement was executed (reached) during the runtime execution.

[whoisj]

@lachbaer I believe the assumption is when the current scope expires, the defer block gets executed. That could be a method, it could be a loop, a conditional, or even just a set of curly braces. Waiting for a method to return could severely limit the usefulness of the statement.

[whoisj]

@leppie no, because the defer Console.WriteLine("foo"); line would not get reached, and therefore the deferred code not pushed onto the scope's stack of deferred statements.

[leppie]

@ghord it would be similar to how I implemented dynamic binding for C# in https://www.codeproject.com/Articles/153896/Dynamic-Binding-in-C

The syntax sugar would imply everything in the block except the defer block, goes into the try block, and the defer block goes into the finally block.

So something like this would be possible:

bool error = false;
if (somethingtrue)
{
    goto skip;
    defer error = true;
    skip: ;  
}
Console.WriteLine(error); // prints true

which is just

bool error = false;
try
{
  if (somethingtrue)
  {
      goto skip;
      skip: ;  
  }
}
finally
{
  error = true;
}
Console.WriteLine(error); // prints true

[leppie]

@whoisj I dont quite agree with those semantics.

Are you saying:

{
    throw new Exception();
    defer Console.WriteLine("foo");
}

should not print?

That seems counter-intuitive, but perhaps thats the weird way people want it....

Edit: I guess it would not be that hard to exclude non-reachable code from being added to 'finally'. Undecided.

[whoisj]

@leppie I am, but I'm no authority here.

I understand defer to more of a "push action onto stack of events".

For example ...

bool error = false;
if (somethingtrue)
{
	goto skip;
	defer error = true;
	skip: ;  
}
Console.WriteLine(error); // prints true

... would be equivalent to ...

bool error = false;
if (somethingtrue) {
	var deferred = new Stack<Action>();
	try {
		goto skip;
		deffered.Push(()=>{ error =true; });
		skip: ;  
	} finally {
		foreach (var action in deferred) {
			action();
		}
	}
}
Console.WriteLine(error); // prints false

[leppie]

@whoisj While that is a semantically correct implementation, it is something I would rather not see the compiler does. Unreachable code is easy to detect, but branching would make this 'likely' impossible to implement in a more efficient way. I dont really see any benefit it would add to the language.

Maybe @gafter can do a magic state machine transform (like yield/async), but boy, so much work for so little...

PS: Nice edit :D

[whoisj]

@leppie if all defer statements are magically setup, then you'll have issues with fun things like:

if (something) {
	var thing = new Thing();
	defer thing.Dispose();
} else if (condition) {
	var foo = new Foo();
	defer foo.Dispose();
} else {
	var thing = new Bar();
	defer thing.Release();
}

Which defer is invoked? How are the thing and foo variables scoped? What type is thing? It gets complicated quickly.

[leppie]

@whoisj Your example does not really explain anything. All the defer is already in a scoped block :D

But yes, I get what you are saying, things will get hairy very quickly. It is nice for the using/lock examples, but we already have syntax sugar for those in C#. And most other use cases can be implemented using using as shown in my previously mentioned article doing 'dynamic binding in C#'.

And implementation could be as simple as (using shorthand):

class Defer(Action defer) : IDisposable
{
  void Dispose() => defer();
}

Usage:

using (new Defer(() => Console.WriteLine("foo")))
{
   blah blah;
   return something;
}

[HaloFour]

The only example of a language that I've found that includes both defer and goto is Go.

func main() {
    goto done
    defer fmt.Println("foo");
done:
}

That does not print foo.

So, I'd say that the equivalent C# shouldn't either. Afterall, that condition likely sets up whatever would need to be deferred. And while goto could probably be considered a little bit of an edge case you run into the same scope shenanigans with switch.

So, given:

{
    goto done;
    defer Console.WriteLine("foo");
done:
}

I'd expect it to emit the equivalent to the following:

{
    bool $temp = false;
    try {
        goto done;
        $temp = true;
        done:
    }
    finally {
        if ($temp) Console.WriteLine("foo");
    }
}

[leppie]

@HaloFour I like your implementation idea, it is much simpler than I thought, and will probably work for 'all' cases I can think of now. If that is the case, then it would a valuable language addition.

IOW, precisely what a compiler should do.

[lachbaer]

@HaloFour that's exactly what I meant by my #513 (comment)! 😃 The only thing I've mistaken was that defer does scope to its surrounding block instead of the whole method.

Btw, wouldn't it be wise to (optionally) extend that block to the scope of a variable?

StreamReader sr = null;
if ([...]) {
    sr = new StreamReader([...]);
    defer (sr) { if (sr != null) sr.Close(); }
}

[CyrusNajmabadi]

Defer doesn't give you any functionality that wasn't there before

Yes it does. It allows you to what you could before in a way that avoids the problems of the existing solutions. That's precisely why it's being discussed.

It's like saying: you don't need lambdas! You could just create callback classes and pass those around!

Yes, it's pedantically true (and yes, people made that argument when we introduced lambdas). But it entirely missed the point. yes, i totally could write:

var underage = customers.Where(new CustomerAgeLessThanPredicate(21));

...

class CustomerAgeLessThanPredicate : IPredicate<Customer> {
   private readonly int _age;
   public CustomerAgeLessThanPredicate(int age) => _age = age;
   public bool Test(Customer c) => c.Age < _age;
}

but that was unpleasant and onerous. The approaches possible today are similar in their problems. And this is something i feel at least weekly as i bounce around these languages. It's just one of those areas where you come back to C# and go "man... this feel so well handled elsewhere, it's a pity they have a half-solutoin today, since it's preventing them from just adopting the better solutoin found elsewhere".

[CyrusNajmabadi]

"Heavyweight to implement in the language" (though, it's not)

Ok. Let's start with something simple. How would you make your suggestion work when the lambda needs to capture something that it's not allowed to capture today (like say, a 'Span'). How do you make it so that we can do something with that span at the end of the scope?

[CyrusNajmabadi]

So, implementing a reusable pattern in a few lines of code which is much more powerful and extensible than a "defer" keyword, is more "heavyweight" than adding a new language feature?

That is literally not what i said. I said i want a solution that does not have the limitations of that approach. :) You literally snipped out that part of the response (i'm going to presume that was not done intentionally). :)

So, implementing a reusable pattern in a few lines of code

The reusable pattern you are suggesting literally will not work for cases where i want to use defer. it's the same reason why you don't see people writing:

Try(() => { ... }, finally: () =>{ ... })

either today. Closures are limited in C#. They're not a general all-purpose substitute for normal control flow logic. Furthermore, it's very un-C#-y to code in this manner. It's not the way that the language has every positioned itself, and it's not found commonly in the ecosystem.

Taking a tiny feature and saying it shouldn't be necessary because people coudl just code in a massively different fashion than today and hoping that if the language can somehow undo the limitations inherent in your alternate proposals, is basically a non-starter. Same as how it's a non-started to put forth the idea that C# will just get metaprogramming, and thus won't need language features anymore since they'll all just run through the metaprogramming language. These approaches are pretty much DOA. So i'm focusing on simple, pragmatic, approaches that can slot into the language trivially, and which can solve these problems realistically, without all the caveats of the alternative heavier approaches.

[thelazydogsback]

"Heavyweight at runtime" (method rewriting, capturing variables etc) is very different to "Heavyweight to implement in the language" (though, it's not)

Any syntax change is a multi-million dollar and years-long change down the chain of client IDEs and plug-ins, web-based IDEs and colorizers, code analysis tools, etc. Again, to me, very not worth it in this case.

Efficiency can be a concern - but:
(a) In these resource allocation cases, they tend to be in contexts where other matters (like waiting on network, string-cating, etc.) are many orders of magnitude more of an issue than a closure
(b) Many of these cases that look like closures should escape-analyzed by the release compile or the JITTer and no actual closures allocated because they don't get passed out of the fn. (I would hope anyway...)
(c) If efficiently is really that much of a concern (you're writing your own scheduler, let's say) then just use long-hand try/finally (which again is more explicit anyway) whether you like the syntactic burden or not.

A matter of personal experience I guess -- but when writing C# I would much rather have a bracketless try/catch/finally expression than a defer keyword - the former I come across all the time, while I don't recall ever being unhappy with "using" to the point I would mind hand-coding any special cases.

[yaakov-h]

This is probably a stupid question, but...

if:

// before defer
defer { /* in defer */ }
// after defer

gets translated to:

// before defer
try
{
    // after defer
}
finally
{
  /* in defer */
}

then could I do this?:

{
    RuntimeHelpers.PrepareConstrainedRegions();
    defer {
        // constrained region
    }
}

? 😄

[CyrusNajmabadi]

Any syntax change is a multi-million dollar and years-long change down the chain of client IDEs and plug-ins, web-based IDEs and colorizers, code analysis tools, etc. Again, to me, very not worth it in this case.

Wat? As someone who has worked in the Roslyn codebase for years, i can tell you that that is not at all true.

This specific feature would be on the order of a couple of man-days (mostly around just writing the tests). There would also be some additional time i would take to add new IDE features to suggest changing compatible code to this form. But that's an optional piece of work that wouldn't be part of the core cost of this feature.

Efficiency can be a concern - but:

Absolutely none of those concerns were things i brought up. They're effectively a strawman. :)

but when writing C# I would much rather have a bracketless try/catch/finally expression than a defer keyword

This doesn't address a core value-prop of defer (which makes it much more conceptually lightweight). Namely, that your defer-code can be logically placed in a much more desirable location. In other words, one of the biggest annoyances today for me with try/finally is needing to have what can be enormous separation between the code that is most logically associated together. defer is effectively a reformulating of an incredibly common try/finally pattern that basically allows for code that reads a lot better today.

I brought this up earlier, but defer is just a natural progression of try/finally through a few steps:

First, start with:

// start of scope code
try
{
     // code
}
finally
{
    // end of scope code
}

Step 1: move the finally first, so the scoping related code is paired off:

// start of scope code
finally
{
    // end of scope code
}
try
{
     // code
}

Step 2: remove the try block and have the try/finally apply to whatever follows the finally.

// start of scope code
finally
{
    // end of scope code
}

// code

Step3: rename 'finally' to 'defer' to read better:

// start of scope code
defer { /* end of scope code */ }

// code

That's really it. It's something with all the power of try/finally, but without the annoyances of it.

Honestly, i think if hte keyword were 'finally', people would not be complaining so much. but, 'finally' doesn't really make sense as a standalone fragment like finally { ... }, and defer { } reads much better. But, if it helps you to think of it as a shorthand try/finally form, be my guest :)

[CyrusNajmabadi]

@yaakov-h

This is probably a stupid question, but...

From teh language's perspective, CERs aren't a thing. It's like asking if you can use a using with CERs. :)

[thelazydogsback]

Wat? As someone who has worked in the Roslyn codebase for years, i can tell you that that is not at all true. This specific feature would be on the order of a couple of man-days ... There would also be some additional time i would take to add new IDE features to suggest changing compatible code to this form. But that's an optional piece of work that wouldn't be part of the core cost of this feature

If you're just talking about MSFT work or work on the local toolchain, sure - but that's not the whole world. (And there are still plenty of tools that use YACC,etc., parser-gen tools or hand-rolled recursive descent parsers and not Roslyn because C# is only 1 of N languages that need to be supported.) Anyway - point taken - I'm not saying it's hard to implement in and of itself.

I'm a huge fan of the power that C# gives me, including new syntaxes like span in combination with BCL and user code, (over Java, let's say) and I promote C# and F# all I can.
And I'm not saying to use monads/fluent-APIs, CPS, closures-as-control-flow, etc., when we have a better, standardized C# ideomatic way of doing things -- only that sometimes it's ok to borrow from these if it is elegant and serves the purpose. If "defer" was there I may use it -- and personally I'd also be fine without it -- you obviously feel more strongly about it, are advocating for it, and by the looks of things you look like you are willing and able to implement it, so more power to you! I just wanted to put in my 0.02 that I thought in C# it didn't give us enough added benefit to add another construct to the language.

if it helps you to think of it as a shorthand try/finally form, be my guest :)

If it's there, feel free to champion your own name :) [Edit: Although @aKzenT makes a good point as well]

[TheBuzzSaw]

@yaakov-h According to my understanding of it, yes, I would expect that to work. Many of us just want defer to be a tool to rewrite/reorder code (in the vein of try/finally). I would die inside if the golang model were used (allocations, a hidden stack of deferrals, tied to function scope instead block scope, etc.).

[aKzenT]

15 year old post, still relevant in my eyes:
https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/

The cost of adding a feature is not only the development time. Just to mention a few:

• Supporting the feature forever in the compiler and all related products. This is often not a one-time task because of refactorings or rewrites.
• Having to consider possible side effects with every new feature that gets added to the language (just like in the case we had to think how it would work with goto and other "special" features)
• Increasing the complexity of code transformations the compiler has to do, therefore increasing the surface for possible bugs. Not to mention the increased complexity of decompilers or other useful tools that try to reverse the transformations.
• Documenting the feature inside and outside of Microsoft
• Cost of new users having to learn additional syntax

For me at least it doesn't has high enough value to outweigh the cost, but as @thelazydogsback said, you feel very strongly about it, so maybe we are missing some of the benefits you see.

As for wording, I would actually prefer to have the keyword be "finally" instead of "defer". In my eyes it would at least make the feature easier to understand for existing C# users. It really is a finally-block that is not bound to a try-block but to the following code within the parent scope. More or less similar to the way the new using-declarations work. And it avoids confusion with the defer statement in other languages which seem to work quite differently.

[YairHalberstadt]

@CyrusNajmabadi
This -100 points sure is interesting. Had you ever heard of it?
😉😂

[HaloFour]

@YairHalberstadt @aKzenT

It is the language designers that determine the points, though. All it takes is a champion to get it into the meetings for consideration and enough of a consensus that it's worth the effort to implement.

[yaakov-h]

Tiny scope, low effort is a great way to quickly gain points. @$/$@ strings got enough in about 15 minutes.

[aKzenT]

Regardless of my scepticism with this feature, I'm not really a fan of the naming of the "defer" keyword itself either. I could imagine using "finally" without a corresponding "try"-block, but it could in some cases not be directly obvious if there is a "try"-block or not. Browsing arround today I noticed that D uses the scope-keyword http://ddili.org/ders/d.en/scope.html and it even seems to be more similar to the proposal here than the defer-statement in swift/go (being tied to the scope instead of the enclosing function). So that got me thinking, why not do something similar in C#:

workers++;
scope finally workers--;

So the finally would mean the same as always and the scope-keyword would make it clear that it is attached to the surrounding scope instead of some try-block. It would also open up the possibility to extend this to failure cases later like it is possible with D's scope(failure):

scope catch(Exception ex) Console.WriteLine($"An Error occurred: {ex.Message}");
// do some work that could trigger an exception

What do you think?

[CyrusNajmabadi]

defer seems reasonable given the similarly named features in go/swift.