Proposal: Expression Bodies

[emperador-ming]

Proposal: Expression Bodies in C#

C# continues to evolve by embracing expressive, concise syntax that reduces boilerplate while maintaining clarity. A proposed feature, Expression Bodies, aims to further streamline code by allowing sequences of statements to be treated as single expressions, without the need for explicit braces ({ }). This builds on the success of existing expression-bodied members (like => for methods or properties) but extends their power to handle multi-step computations naturally.

How It Differs from Expression blocks (#3086 & #9242)

While both proposals aim to unify statements and expressions, Expression Bodies eliminate the need for curly braces { } to denote block boundaries. Instead, expression bodies use a double semicolon ;; only on the final statement to signal the end of the expression body. This creates a more fluid, intuitive syntax that aligns with C#’s existing patterns. For instance:

var result =  
    var x = ComputeValue();  
    x * 2;;  // No braces needed; `;;` marks the end  

This contrasts with Expression Blocks, which require braces even for single-line expressions, adding visual noise.

Key Conclusions:

1. Minimize Conceptual Overhead: Expression Bodies behave like traditional blocks semantically—control flow (e.g., return, break) exits the enclosing function or loop, not the expression itself, ensuring alignment with C#’s existing behavior.
2. Consistency and Compatibility: The feature integrates seamlessly with C# conventions, allowing nesting within other blocks or expressions for predictable composability.
3. Simplicity and Familiarity: By extending C#’s expression-oriented approach, Expression Bodies prioritize clean, declarative code without introducing new paradigms.

Expression Bodies Rules:

1. Result Cannot Be Discarded
2. Double Semicolon ;; Only on Last Statement
3. All Code Paths Must Return a Value
4. No return Keyword in Final Statement
5. Declarable Within Code Blocks: Expression bodies can be used in methods, properties, or nested scopes
6. Nesting Allowed: Expression bodies can contain other expression bodies

These rules and principles reinforce C#’s evolution toward concise, expressive syntax while maintaining clarity and alignment with existing language semantics.

Rule 1: The result of an expression body cannot be discarded.

The following is an expression body because 1;; is an expression terminated with two semicolons.

_ = 1;;  // it doesn't compile

However, it does not compile because the result of an expression body cannot be discarded.

Rule 2: Only the last statement in an expression body ends with two semicolons.

The following is an expression body. The result of the expression body has been assigned to an integer variable named a:

int a = 1;;

The following is not an expression body:

// not an expression body
int a = 1;
int b = 2;
int c = a + b;

The following is neither an expression body because only the last statement in an expression body ends with a semicolon.

// not an expression body
var c =
    var a = 1;; // only the last statement in an expression body ends with a semicolon!
    var b = 2;; // only the last statement in an expression body ends with a semicolon!
    a + b;;

The following is an expression body:

// OK
int c =
    int a = 1;
    int b = 2;
    a + b;;

The following is also an expression body:

// OK
var c =
    var a = 1;
    var b = 2;
    a + b;;

Rule 3: All code paths of an expression body must return a value.

The following is not an expression body because not all code paths return a value.

// not all code paths return a value
var isNull = if(a is null)
{
    return false;;
}

Rule 4: The last statement of an expression body must not contain the return keyword

The following is not an expression body either because the last statement of an expression body must not contain the return keyword.

// not an expression body
var isNull = if(a is null)
{
    return false;
}
else
{
    return true;; // last statement must not contain the return keyword
}

The following code snippet is a valid expression body:

// if-else expression body
var isNull = if(a is null)
{
    return false; // ';' is optional
}
else
{
    true;;
}

These are also valid expression bodies:

// if-else expression body
var isNull = if(a is null)
    false // ';' is optional
else 
    true;;

// if-else expression body
var isNull = if(a is null) false else true;;

Rule 5: Expression bodies can be declared in a block of code.

The following methods are equivalent

public int Three()
{
    int one = 1;
    int two = 2;

    return one + two;
}

public int Three() => // expression body
    int one = 1;
    int two = 2;
    one + two;;

The following is not a method with an expression body

[HttpGet]
public async Task<IResult> Get(string? initials = default, CancellationToken cancellationToken = default)
{
      var user = string.IsNullOrEmpty(initials) 
          ? UserValue.From(_user.Value) 
          : UserValue.From(initials);
      try
      {
           var (_, costCenters) = await _invoicesService.GetCostCentersAsync(user, cancellationToken);
           return Results.Ok(costCenters);
      }
      catch (Exception ex)
      {
           return ex.AsResult();
      }
}

This is the same method with an expression body:

[HttpGet]
public async Task<IResult> Get(string? initials = default, CancellationToken cancellationToken = default)
{
  return
      var user = string.IsNullOrEmpty(initials) 
          ? UserValue.From(_user.Value) 
          : UserValue.From(initials);
      try
      {
          var (_, costCenters) = await _invoicesService.GetCostCentersAsync(user, cancellationToken);
          return Results.Ok(costCenters); 
      }
      catch (Exception ex)
      {
          ex.AsResult();; // Rule2: Only the last statement in an expression body ends with two semicolons
      }
}

However, preferred alternatives are:

[HttpGet]
public async Task<IResult> Get(string? initials = default, CancellationToken cancellationToken = default) => // expression body
    var user = string.IsNullOrEmpty(initials) 
        ? UserValue.From(_user.Value) 
        : UserValue.From(initials);
    try
    {
        var (_, costCenters) = await _invoicesService.GetCostCentersAsync(user, cancellationToken);
        return Results.Ok(costCenters); 
    }
    catch (Exception ex)
    {
        ex.AsResult();; // Rule2: Only the last statement in an expression body ends with two semicolons
    }

public async Task<IResult> Get(string? initials = default, CancellationToken cancellationToken = default)
{
     var user =
        if(string.IsNullOrEmpty(initials))
            UserValue.From(_user.Value);
        else 
            UserValue.From(initials);;
    
    try
    {
        var (_, costCenters) = await _invoicesService.GetCostCentersAsync(user, cancellationToken);
        return Results.Ok(costCenters);
    }
    catch (Exception ex)
    {
        ex.AsResult();;
    }
}

The following is an expression body used in a block of code

static string TheDreamIsFree(Hustle hustle)
{
    if(hustle.IsSoldSeparately)
    {
        throw new InvalidOperationException();
    }
  
    var c = 'C';
    var sharp = '#';
  
    // expression body  
    var version =
        var v = 10;
        var hope = 4;
        $"{v+hope}";; // "14"
        
    return $"{c}{sharp} {version}"; // "C# 14"
}

Rule 6: Expression bodies can be declared inside expression bodies.

static string TheDreamIsFree(Hustle hustle)
{
    if(hustle.IsSoldSeparately)
    {
        throw new InvalidOperationException();
    }
  
    // expression body
    var theDreamIsFree =
        var c = 'C';
        var sharp = '#';
    
        // expression body declared inside previous expression body
        var result =
            var v = 10;
            var hope = 4;
            $"{c}{sharp} {v+hope}";; // yields "C# 14" 
    
        result;; // yields "C# 14"
  
    return theDreamIsFree;
}

Some More Examples

static bool TryPrintLine(Func<T> fun) => // expression body
    try
    {
        var val = fun();
    }
    catch
    {
        return false;
    }
    Console.WriteLine(val);
    true;;

static int FibonacciSwitchEfficient(int n) => n switch
{
    0 => 0,
    1 => 1,
    _ => int a = 0, b = 1;
         for (int i = 2; i <= n; i++)
         {
            int temp = a + b;
            a = b;
            b = temp;
         }
         b;;
};

static IEnumerable<int> GetEvenNumbers(int limit) =>
    for (int i = 0; i <= limit; i++)
    {
        if (i % 2 == 0)
        {
            Console.WriteLine($"Generating: {i}");
            yield i;; // Rule 4: Last statement must not contain the return keyword 
        }
    }

See also

#377
#9242

LDM 2020-01-22
https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-09-26.md#discriminated-unions
https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-08-28.md#block-bodied-switch-expression-arms

I think for this feature to work it should connect as much as possible to the existing block feature, to the point where an expression block is a block from a conceptual perspective, and quite possibly from a grammar perspective. We want to keep the conceptual overhead as low as possible, and have as few surprising syntactic and semantic differences as possible.

I currently think this means the following:

A block expression should behave like a block. That should be the guiding design principle. In every decision that isn't directly about the thing that is inherently different from today's blocks (i.e. getting a result value out) we should do what blocks do.

This means that:

• return returns from the nearest enclosing function (be it a lambda, a method, an accessor, etc.), not the block itself

• Transfer of control to the outside with break, continue and goto all work the same way (i.e. we should figure out the evaluation stack issue)

When meaningful, expression blocks should be available where blocks are. Functions, including methods, should not be required to use return e; statements for producing values from block bodies. They can just be blocks with results:

double GetLength() { var (x, y) = GetCoordinates(); Math.Sqrt(x*x + y*y) }

Of course, as always, I am entirely open for convincing, including being convinced out of doing the feature at all! 😀

Originally posted by @MadsTorgersen in #3086

[HaloFour]

An expression body must be properly indented.

C# is not a whitespace sensitive language. Blocks/scoping should have nothing to do with indentation.

Also, see: #9243 (Oops, paste fail)

[timcassell]

#9242

[emperador-ming]

@HaloFour
Expression bodies could work just as well without the indentation requirement. Should I edit my proposal or create another one?

[jaredpar]

I would edit in place vs. opening a new one but I agree with @HaloFour that a feature dependent on white space is unlikely to be accepted.

[HaloFour]

IMO it's probably better to keep it on the existing discussion on this subject, especially as this is really just suggesting different syntax: #9242

[emperador-ming]

@HaloFour, @jaredpar, @timcassell
Thank you for the feedback! I’ve updated the Expression Bodies proposal to remove any whitespace/indentation dependency. The revised syntax no longer requires indentation for scoping, aligning with C#’s design principles.

Additionally, the proposal now explicitly references and integrates insights from the existing discussion in #9242, ensuring continuity with prior syntax explorations.

The updated rules focus on clarity, compatibility with existing block semantics, and minimal conceptual overhead—consistent with Mads Torgersen’s guidance. Your input has been invaluable in refining this proposal!

[Austin-bryan]

I'm just struggling to see the use case. Many examples could be rewritten to avoid using this feature and still be a one liner.
The most useful case was the if/else in a single line but you can already do this with the ternary operator.

If readability is such a concern and you want a clear assignment of a value to a variable, you can just put the logic in a method/local function and then it'll be even easier to read because it'll be named.

[ghost]

I advocate for this as a general concept in whatever the released form may be. Further elimination of braces and similarity to F# is good!