Proposal: Introduction of Object Statement Blocks

[BN-KS]

This Proposal is to add Object Statement Blocks to C# where the object.{/statements/} is made generally available as a syntax.

Example:

someObject.{
    someMethod();
    someOtherMethod();
};

This could be used in conjunction with Object Initializers. This could allow for even more flexibility, letting developers choose the most appropriate syntax for their needs:

var order = new Order {
    OrderId = orderId,
    ProductName = product.Name
}.{
    ProcessOrder();
};

Additionally you could use encapsulation and do this:

(order ??= new Order() {/*initializer*/}).
{
    /*statements*/
};

This encapsulation would allow the code block to be applied to either the existing or the new object, resulting in a significantly cleaner syntax and reduced code.

Benefits of This Proposal:

1. Improved Readability: Keeping related logic together enhances clarity and maintainability.
2. Flexibility: Developers can choose the most suitable syntax for their specific use cases.
3. Streamlined Initialization: This approach reduces verbosity and improves the overall flow of code.

Current Workarounds

Developers currently handle complex initializations through multiple steps, resulting in code that may be less readable. Our proposal aims to provide a cleaner, more concise way to achieve the same outcomes.

This is different than the request for expression blocks here:
#3086
And sort of related here:
#5808
But this feature would be notably and distinctly different

[AderitoSilva]

I like this, specially when used with the fluent pattern.

[HaloFour]

How would this work with switch expressions, which aren't dotted off of any instance?

[HaloFour]

That's precisely the point of the proposals, there is no syntax like that in C#. Arrow functions aren't a thing and code blocks don't "yield" values on their own. That behavior would already conflict with the behavior of lambdas.

[BN-KS]

Well if you can't do it today, this isn't a proposal to change how the switch statement works today. But in the interest of due diligence, you could use the more traditional switch block with ":" and combine it with this feature

switch (s) // Traditional switch statement
{
    case "a":
        Console.WriteLine("a");
        break;

    default:
        s2 = s.ToUpper().{/*Code Block*/};
        Console.WriteLine(s2);
        break;
}

[HaloFour]

You had linked this proposal to the expression block proposal, so I had assumed you had intended it as an alternative. It doesn't seem to be one if it doesn't handle those use cases. If expression blocks are added to the language properly I question the value of this proposal as a standalone feature. It feels like a form of with.

[vladd]

@HaloFour
1 => 1.{ /* block here */ },?

[BN-KS]

@vladd is there a use case for how you would want to handle that case? Are you trying to solve a problem with using it here, or just curious what the expected outcome would be and wanting it to not be ambiguous or ensure it throws a compiler error or something?

Obviously 1 is a constant but the control flow would be the same, the one would be yielded after the block expression runs, obviously it can't change the value (which is probably a nice safeguard) but we could still have other actions take place

1 => 1.{ DidWeUseOne = true;},

[BN-KS]

The initial use case for me was to help stay more DRY as I hate repeating myself when coding so whenever I do, I start to think of ways in which things could be better or more streamlines.

//So we can change this common pattern:
var someVariable = someWayToGetSaidVariable();
someVariable.DoSomething();
someVariable.DoSomethingElse();
someVariable.MoreStuff().MoreStuff();

//Into this;
var someVariable = someWayToGetSaidVariable().{
    DoSomething();
    DoSomethingElse;
    MoreStuff().MoreStuff();
}

//Or in some cases, better or at the least more compactly as a one liner:
var someVariable = someWayToGetSaidVariable().{ DoSomething(); DoSomethingElse; MoreStuff().MoreStuff();}

Remember it's not lazy, it's just efficient ;)

[HaloFour]

var someVariable = someWayToGetSaidVariable();
someVariable.DoSomething();
someVariable.DoSomethingElse();
someVariable.MoreStuff().MoreStuff();

I don't see anything about this that violates DRY. Being more terse doesn't make it more efficient. It think it makes it much more challenging to read, and that's a substantially more critical aspect to code than how many characters it takes to convey.

[BN-KS]

You repeated the same variable name 4 times when you only need it once. That to me isn't very DRY

[Ghost4Man]

This reminds me of Dart's cascade notation and Kotlin's apply. These, and the classic use of method chaining for fluent interfaces, all solve the problem of configuring a value through methods, possibly inside a nested expression, where you can't just declare a variable (at least not until we have block expressions, but even with those, the code could still be very verbose).

Possible example of UI code:

var mainWindow = CreateWindow("My App").{
    Maximize();
    SetContent(new StackPanel(Direction.Horizontal).{
        Items.Add(new TextBox { Placeholder = "Your name" }.{
            ValueChanged += ValidateName;
        });
        Items.Add(CreatePasswordInput().{ Placeholder = "Password" });
        Items.Add(CreatePrimaryButton().{
            Text = "Login";
            Icon.LoadFrom("login-icon.png");
            SetClickHandler(async () => { await LogIn(); });
        });
    });
    SetTheme(MyApp.Themes.Dark);
    InitializeLayout();
}

To write code like this today, you either have to use method chaining (using a fake return value of this instead of void or something actually useful) if you have control over all of the code, or write some ad-hoc extension method (probably too unidiomatic to pass code review) if you don't. Or give up on readability and just place every subexpression into its own variable (where you won't see where it's used, what container the UI element belongs to, etc.).