C# Expression Blocks - Let's make C# more expressive

[AderitoSilva]

I propose a new feature for C#, for which I would like your opinions about. I propose Expression Blocks.

Expression Blocks would improve the way we use the fluent pattern, simplify the initialization of auto properties, allow us to use statements in places where only expressions can be used, and more. It uses familiar syntax, and is fully compile time — it is just syntactic sugar.

What are expression blocks

They are a block of C# code that can produce a value for an expression or process an expression value.

Produce a value

An expression block that produces a value would be similar to the block of a property getter. An expression would be a C# block inside brackets { }, that have return statements.

this.ExecutePetBehavior({ 
    PetBehavior behavior = new();
    if (IsDog && HatesCats)
        behavior.DisableCatNightmareMode();
    else if (IsCat)
        behavior.DisallowTableScratching();
    return behavior;
});

Process a value

An expression block that processes values is a block of C# inside brackets { } that has a value parameter and can return a value. This block comes after the expression value, similar to the new() { } initializer blocks. return statements here are optional. When the block execution reaches the end, it implicitly returns value (which might have been changed in the block), unless an explicit return is called before.

For conditionally processing a value

It is useful for when we want to process/mutate and/or use an alternative value. Notice that there is no return in the end of the block, because it is not necessary — it implicitly returns value.

MyClass GetReady() => GetCurrent()
    {
        if (value.IsReady())
            return value;
        value = GetPrevious();
        if (!value.IsReady())
            throw new NotReadyException(value);
    };

For mixing with statements

It is useful for when we just need to further process/mutate a value without breaking a call chain (for example, in the fluent pattern).

public MyClass Instance => GetInstance()
{
    if (!value.IsInitialized)
        value.Initialize();
};

Concept

The concept of an expression block is just that it is an anonymous local method:

• If the expression only produces a value, like var a = { return 10; };, it is just an anonymous parameterless method that returns a value of the expected type.
• If the expression processes a value, like var a = b { return value * 2; };, it is just an anonymous method that receives a parameter (value) and returns a value of the same type.

Like in local methods, expression blocks have their own scope and have access to the outside scope. Unlike local methods, they are "anonymous" methods, written in-place, that cannot be reused.

Because expression blocks return a value, they can be followed by another expression block or by operators, like any other expression. For example, all these would be valid:

• var a = b { return value * 2; } { return value + 5; };
• var a = b { return value * 2; }.ToString();
• var a = b { return value * 2; } { return value + 5; }.ToString();

What does this feature solve

Alternative to complex ? : chains in expressions

The use of the ternary conditional ? : operator gets messy when there is more than one branch. Expressions like a = x > 10 ? c : x < 0 ? d : e; would be simplified to a more readable if block inside an expression block.

// This
Pet? petFromName = {
    if (name is "Kiki" or "Koko")
        return new Dog(name);
    else if (name is "Bubba" or "Garfield")
        return new Cat(name);
    else
        return null;
};

// Instead of this
Pet? petFromName =
    name is "Kiki" or "Koko"
    ? newDogName(name)
    : name is "Bubba" or "Garfield"
    ? new Cat(name)
    : null;

Reuse expression result

A value in an expression can be reused in the same expression. This is useful when a sub expression is expensive to evaluate and must not be evaluated more than once if we need to reuse its value inside the expression.

// This
MyMethod(Parse(complexString) 
{ 
    if (string.IsNullOrEmpty(value))
        return "alternative";
});

// Instead of this
string parsedString = Parse(complexString);
if (string.IsNullOrEmpty(parsedString))
    parsedString = "alternative";
MyMethod(parsedString);

Fluent pattern

Expression blocks would make it easier to produce and/or process an expression value without breaking a call chain. This would be useful with the fluent pattern.

petService.Configure()
    .AddCats()
    { if (builder.Configuration.AreDogsAllowed) value.AddDogs(); } 
    .AddBirds()
    {
        if (builder.Configuration.AutoRunPets)
            value.Run();
    };

Enumerables

Expression blocks should support the yield keyword. This allows for more complex processing of enumerables, that would not be as practical if using LINQ. This might need some more thought when we take implicit return statements into consideration, though.

var initializedItems = GetAll()
    .Where(i => i.IsValid)
    { return value.Any() ? value.Take(10) : GetDefaultItems() }
    {
        foreach (var item in value)
        {
            item.UpdateSize();
            if (item.IsBig)
                yield return MakeSmall(item);
            else
                yield return MakeBig(item);
        }
    }
    .ToArray();

Scope isolation

With expression blocks, you can make an entire method just a structure of scopes.

MyMethod(int arg)
{
    var methodScopeVar = 0;
    // Return chain
    return
    {
        var scope1Var = 1;
        return
        {
            var subScope1Var = 1.1;
            // var subScope1Var = scope1Var;  // Prints 1
            // var subScope1Var = methodScopeVar;  // Prints 0
            // var subScope1Var = arg;  // Prints the vale of `arg`
            return -1;
        }
    }
    {
        var scope2Var = methodScopeVar + 2;
        // var scope2Var = scope1Var;  // Would not compile
        // var scope2Var = subScope1Var;  // Would not compile
    };
}

This would be useful in scenarios where you want to divide a method into very small tasks that produce a value, but you would benefit if local variables would not interfere with each other. This is already possible with local methods, though.

GetDynamicFilePath()
{
    string directoryName =
    {
        string name;
        // Determine the value of `name`;
        return name;
    };
    string fileName =
    {
        string name;
        // Determine the value of `name`;
        return name;
    };

    return Path.Combine(Root, directoryName, fileName);
}

More expressive code

Expression blocks would allow us to use statements in places where only expressions would be allowed. For example:

// This:
public MyClass Instance { get; } = new() { } { value.Init(); }

// Instead of this:
public MyConstructor()
{
    Instance = new();
    Instance.Init();
}
public MyClass Instance { get; }

The example above also demonstrates how it would work with the new initializer blocks. We would always need to include an initializer block before we use an expression block, when instantiating objects with new.

Some additional considerations

The value keyword

Because the value keyword is used in property setters, we might be unable to use expression blocks in property setters. To solve this, some other keyword could be used, instead of value. My suggestion of value is just to make the proposal more clear, but I suggest the use of other keyword for expression blocks, to prevent conflict with property setters.

Async code inside expression blocks

The use of await inside an expression block would have the same effect as it has when we now use it in an expression (like var a = await DoSomethingAsync();). However, I think I don't have enough expertise with async/await to have a clear big picture on all edge cases.

[333fred]

Duplicate of #3086.

[AderitoSilva]

Duplicate of #3086.

I was unable to find that proposal before posting this one. However, I still think my proposal is different from that one, despite the identical name.

[333fred]

They are identical in meaning. Both are about creating a scope, inside of an expression, where statements can be placed. What specific syntax to use is part of the debate, certainly, but it's not different.

[HaloFour]

An expression would be a C# block inside brackets { }, that have return statements.

As noted in the other discussion, this is already legal C# syntax, but the return statement does not exit the block, it exits the entire method in which the block is contained.

[AderitoSilva]

I'm thinking of expression blocks like if they were methods, similar to property getters/setters. In the block, you are like in a local method — you have access to variables and members from outside, just like in a local method, but everything you do inside the block is just like what you would do in any other method. Hence, my proposal for the use of return.

[333fred]

My contention is that treating a block as a very different thing, where return has a drastically different behavior, based solely on weather the result of a block "expression" is assigned to something, would be a very bad design and lead to a lot of confusion.

I get that, and I'm of the same opinion. It's interesting to note though, that in the notes from last Wednesday I haven't finished yet, a couple members of the LDM actually expressed opinions that more match with @AderitoSilva.

[HaloFour]

@333fred

It's interesting to note though, that in the notes from last Wednesday I haven't finished yet, a couple members of the LDM actually expressed opinions that more match with @AderitoSilva.

Well, if the proposed alternative was out I can probably understand why. But I hope saner minds prevail. I guarantee you someone is also going to want to be able to return from the containing method from within an expression block. 😀

[CyrusNajmabadi]

I'm ok with 'return' meaning something for both blocks, and for lambdas. Both are easy to identify, making the meaning of the return clear.

I'm very wary of return meaning something different from an expression block, which I believe will be harder to identify at a glance.

[jnm2]

Guessing "birthday" was meant to be "both" 😂

[nuiva]

Fluent method chaining with expression blocks is a novel idea (and not included in the actual expression block proposal, I believe), but it feels like an orthogonal feature since you can't normally just plop an expression in the middle of a method chain. The syntax also feels dangerously close to object initialization, e.g. the following is valid C# today:

var obj = new MyObject()
{
    value = "foo" // If I add semicolon here, does this turn into an expression block?
};

For fluent expression chaining, I believe the better route would be to add basic expression blocks from the other proposal and then orthogonally add the pipeline operator feature (C# 1, C# 2, JS, C++). Unfortunately, other languages have proven that pipeline operators are a major source of bikeshedding, so this might be too hopeful.

[AderitoSilva]

Fluent method chaining with expression blocks is a novel idea (and not included in the actual expression block proposal, I believe), but it feels like an orthogonal feature since you can't normally just plop an expression in the middle of a method chain. The syntax also feels dangerously close to object initialization, e.g. the following is valid C# today:

var obj = new MyObject()
{
    value = "foo" // If I add semicolon here, does this turn into an expression block?
};

For fluent expression chaining, I believe the better route would be to add basic expression blocks from the other proposal and then orthogonally add the pipeline operator feature (C# 1, C# 2, JS, C++). Unfortunately, other languages have proven that pipeline operators are a major source of bikeshedding, so this might be too hopeful.

In the case of object initializers, it would be required to have the initializer block and the expression block, like in one of the examples I mentioned.

var obj = new MyObject() 
{ 
    // Initializer. Maybe empty, but it's always required for using expression blocks.
}
{
    // Expression block.
};