Proposal: Add the ability to execute arbitrary code in instance initializers

[marksmeltzer]

Let me know if something like this has already been proposed or discussed. I saw #1243 but it isn't the same.

Background

Currently we have to write initialization logic like this:

var textblock = new TextBlock
{
    Width = 172,
    Height = 80,
    TextWrapping = TextWrapping.Wrap,
    Foreground = Brushes.Orange,
    FontFamily = new FontFamily( @"Baskerville Old Face" ),
    FontSize = 72,
    Text = "Hello",
};

textblock.SetValue( Canvas.LeftProperty, 109 );
textblock.SetValue( Canvas.TopProperty, 109 );

Any logic that isn't explicitly a property setter, must be done as actual code following the initializer. There are often many things that need to be initialized that are not properties. So we end up having to write a lot of follow up lines of code referencing the instance being initialized by variable name.

While the proposed syntax would have an economical advantage of saving keystrokes, it would also have an advantage of reducing opportunities for programming errors and also allow the compiler and language tools to infer more information about the programmer's intent regarding initialization logic.

That extra captured intent could help create some specific, useful code analyzers, etc.

Proposal

Amend the C# compiler to support this syntax (or something like it) -- and I'm using a made-up keyword foo in place of some as of yet undecided keyword -- for declaring arbitrary inline multi-statement initialization code blocks:

var textblock = new TextBlock
{
    Width = 172,
    Height = 80,
    TextWrapping = TextWrapping.Wrap,
    Foreground = Brushes.Orange,
    FontFamily = new FontFamily( @"Baskerville Old Face" ),
    FontSize = 72,
    Text = "Hello",
    {
        foo.SetValue( Canvas.LeftProperty, 109);
        foo.SetValue( Canvas.TopProperty, 109);
    }
};

It should also support this single statement syntax suggested by @YairHalberstadt:

var textblock = new TextBlock
{
    Width = 172,
    Height = 80,
    TextWrapping = TextWrapping.Wrap,
    Foreground = Brushes.Orange,
    FontFamily = new FontFamily( @"Baskerville Old Face" ),
    FontSize = 72,
    Text = "Hello",
    SetValue( Canvas.LeftProperty, 109);
    SetValue( Canvas.TopProperty, 109);
};

The multi-line code block syntax could be achieved using a delegate style if a new keyboard doesn't seem like a good idea:

var textblock = new TextBlock
{
    Width = 172,
    Height = 80,
    TextWrapping = TextWrapping.Wrap,
    Foreground = Brushes.Orange,
    FontFamily = new FontFamily( @"Baskerville Old Face" ),
    FontSize = 72,
    Text = "Hello",
    t => {
        t.SetValue( Canvas.LeftProperty, 109);
        t.SetValue( Canvas.TopProperty, 109);
    }
};

Benefits

I mentioned some of these already in the background section, but here they are again:

• it's trite, yes, but this syntax saves keystrokes
• this syntax better captures the programmer's intent (could open up scenarios for some nifty analyzers)
• this syntax can eliminate potential bugs were the wrong instance variable could accidentally be referenced with explicit initialization code
• this syntax would makes it possible to write fluent style deep graphs of initialization code without having to resort to "tricks" like extension methods with delegates for the init logic

Implementation

The code from the Proposal section should be rendered by the compiler into expanded C# to exactly match the code in the Background section. That means the compiled code should be fully backwards compatible.

In other words, I believe this can be implemented as a compiler only change and not have any implications for the CLR, etc.

[marksmeltzer]

An alternative syntax could be something like this which doesn't use the this keyword:

var textblock = new TextBlock
{
    Width = 172,
    Height = 80,
    TextWrapping = TextWrapping.Wrap,
    Foreground = Brushes.Orange,
    FontFamily = new FontFamily( @"Baskerville Old Face" ),
    FontSize = 72,
    Text = "Hello",
    t => {
        t.SetValue( Canvas.LeftProperty, 109);
        t.SetValue( Canvas.TopProperty, 109);
    }
};

However, I think using this in the init logic should be safe -- because the init logic should only have access to the instance being initialized, and not any of its parents, etc.

[CyrusNajmabadi]

Having this not mean "the containing type's instance" would be a big deviation from how C# has worked since v1. I would be highly loath to allow that. You could always support something VB'ish like:

    FontSize = 72,
    Text = "Hello",
    .SetValue( Canvas.LeftProperty, 109),
    .SetValue( Canvas.TopProperty, 109),
};

[marksmeltzer]

@CyrusNajmabadi in this proposal, the this keyword does retain exactly that meaning though in scope of the initializer logic. That's the intent anyway. If that feels like too big of a stretch, then another keyword could be introduced or the delegate syntax could be used. Personally I think this nicely captures the intent though.

I did see another proposal to allow more generous fluent style programming that looks similar to the syntax you just provided. I wasn't a huge fan of that proposal though, as it involved many logical conundrums.

[marksmeltzer]

@CyrusNajmabadi the goal of this proposal is to allow arbitrary code to be executed in the initializer block -- not just call methods on the instance being initialized. The goal would be to allow doing anything a normal code block would be able to do -- like declare scoped variables, have multiple statement logic, loops, etc.

[CyrusNajmabadi]

@CyrusNajmabadi in this proposal, the this keyword does retain exactly that meaning though in scope of the initializer logic.

Riht. That's my point. up till now 'this' has never changed meaning. that's actually been something very intentional (i.e. inside a lambda, it's a lexical capture, unlike how JS works). It would def likely be too much of a stretch as i don't think it would be palatable at all to change that now.

Personally I think this nicely captures the intent though.

The main issue is that you've now changed how this is seen in 100% of all code since the dawn of C#. that's a major break with expectations :)

[Mike-E-angelo]

nodding along with @CyrusNajmabadi ... "this" (sorry 😅) is a nifty proposal, but a new keyword should (read: MUST 😁) be considered.

@VincentH-Net, you might dig this (check out his cool project that dances around this problem space here).

[YairHalberstadt]

Why not just:

var textblock = new TextBlock
{
    Width = 172,
    Height = 80,
    TextWrapping = TextWrapping.Wrap,
    Foreground = Brushes.Orange,
    FontFamily = new FontFamily( @"Baskerville Old Face" ),
    FontSize = 72,
    Text = "Hello",
    SetValue( Canvas.LeftProperty, 109);
    SetValue( Canvas.TopProperty, 109);
};

?

[marksmeltzer]

@CyrusNajmabadi and @mike-eee I'm not too interested in debating the semantic point, as that is a secondary concern. I'm fine with a new keyword or the delegate style syntax or this. As far as the proposal itself goes, this specific part of the conversation seems like bikeshedding.

However, even if this is is just bikeshedding, I don't see the proposed syntax as changing the critical expectations around this: code inside a constructor uses this to refer to the instance being constructed. Analogously, code inside an initializer block could use this to refer to the instance being initialized. There's nothing drastically different going on in that new syntax. It follows the same analogies that already exist.

What's unique about my preferred syntax is giving C# authors the ability to write arbitrary code blocks as if they were declared on the type being referred to. I'll give you that. That's certainly never been done before in C#. Previously, this has always canonically referred to the instance that entered the current method. So, sure that part is a change, and sure, perhaps it is a bad idea.

As I said I am not opposed to a new keyword in place of this or simply using the delegate style syntax.

[marksmeltzer]

@YairHalberstadt I would not mind one bit if that was also supported. I would like the ability to put a code block in the initializer though, which was what the original proposal was mostly about -- even if the example I picked was a bit simplistic.

[CyrusNajmabadi]

There's nothing drastically different going on in that new syntax.

Literally for 20 years this has meant one thing no matter where you found it in an expression context :) Your proposal would change that. That's definitely a 'drastic' change.

    ...
    Text = this.Foo;
    this.SetValue( Canvas.LeftProperty, 109),
};

Two usages of this, one which means the same thing it always has in C#, and one which means "the outer variable which is getting constructed". This is going to be confusing :)

[marksmeltzer]

@CyrusNajmabadi thanks. that helps highlight the potential issues with using this.

I am going to edit the original proposal to remove use of this to avoid promulgating this line of the discussion.

[marksmeltzer]

Okay. I edited the proposal and included @YairHalberstadt's suggestion.

[YairHalberstadt]

Why not:

var textblock = new TextBlock
{
    Width = 172,
    Height = 80,
    TextWrapping = TextWrapping.Wrap,
    Foreground = Brushes.Orange,
    FontFamily = new FontFamily( @"Baskerville Old Face" ),
    FontSize = 72,
    Text = "Hello",
    {
        SetValue( Canvas.LeftProperty, 109);
        SetValue( Canvas.TopProperty, 109);
    }
};

?

[Mike-E-angelo]

I totally missed @CyrusNajmabadi's suggestion, but I think this is the right way to go:

    FontSize = 72,
    Text = "Hello",
    .SetValue( Canvas.LeftProperty, 109),
    .SetValue( Canvas.TopProperty, 109),
};

Or maybe something unique/different/new:

    FontSize = 72,
    Text = "Hello",
    ..SetValue( Canvas.LeftProperty, 109),
    ..SetValue( Canvas.TopProperty, 109),
};

Anyways, if this is what we're nitting about, then this proposal has a lot going for it, yes? :)

[YairHalberstadt]

Essentially let's break this up into two orthogonal proposals:

1. Allow initialisers to contain blocks.
2. Allow initialisers to call methods.

[Mike-E-angelo]

@YairHalberstadt I am thinking about it from an indexing listing of the available symbols at a particular location. Pressing . will "enter" you into the selection process. Otherwise, you will have to know the exact symbol you are looking for.

For me at least, the . is more natural to enter/describe the next symbol, but I am not glued to it.

[YairHalberstadt]

@mike-eee

Intellisense already does this for object initialisers and properties. I don't see why method should be different.

[Mike-E-angelo]

Yeah good point @YairHalberstadt ... my creativity got the better part of me. 😆

[marksmeltzer]

@YairHalberstadt I would be fine with no keyword required at all. That's certainly very economical.

I just wonder if the type being initialized has a method with the same name as static a method in the outer scope, it might be confusing for both the reader and the compiler which method is being referred to.

For example:

private static void SetValue( object someObj, object someValue )
{
  throw new NotSupportedException("Wrong method called!");
}

private TextBlock SomeMethod( )
{
    var textblock = new TextBlock
    {
        Width = 172,
        Height = 80,
        TextWrapping = TextWrapping.Wrap,
        Foreground = Brushes.Orange,
        FontFamily = new FontFamily( @"Baskerville Old Face" ),
        FontSize = 72,
        Text = "Hello",
        {
            SetValue( Canvas.LeftProperty, 109); //what method will be called?
            SetValue( Canvas.TopProperty, 109); //what method will be called?
        }
    };

    return textblock;
}

[CyrusNajmabadi]

I just wonder if the type being initialized has a method with the same name as static a method in the outer scope, it might be confusing for both the reader and the compiler which method is being referred to.

That's why i'm proposing that you do: .SetValue( Canvas.LeftProperty, 109).

Note: this is basically exactly what VB does with with blocks.

[marksmeltzer]

If #1449 gets approved, it may be good to include this proposal in the syntax for that feature since it looks very similar to the initializer syntax.

Although, it might have less utility in that context.... Since #1449 doesn't exist, I haven't really felt and cannot predict whether this capability would be sorely missed if it weren't included in #1449.

[marksmeltzer]

There's also some potential overlap/symmetry with #803, #2355, #1879, #1534, etc.

[DavidArno]

this syntax would makes it possible to write fluent style deep graphs of initialization code without having to resort to "tricks" like extension methods with delegates for the init logic

This is the bit I'm really struggling with. What you are proposing encourages void methods and so is the exact opposite of using a fluent solution. And fluent solutions already work using existing syntax:

private TextBlock SomeMethod()
{
    return new TextBlock
    {
        Width = 172,
        Height = 80,
        TextWrapping = TextWrapping.Wrap,
        Foreground = Brushes.Orange,
        FontFamily = new FontFamily(@"Baskerville Old Face"),
        FontSize = 72,
        Text = "Hello"
    }
    .SetValue(Canvas.LeftProperty, 109)
    .SetValue(Canvas.TopProperty, 109);
}

I see no positive benefit to this proposal unfortunately. So it's a 👎 from me.

[marksmeltzer]

@DavidArno

First, IF a fluent API already exists, then this new syntax doesn't add value. You are correct.

However, fluent APIs in many cases do not and will not ever exist - or at least, the old APIs cannot be made fluent because it would be a breaking change to the current method signatures.

Second, your criticism/concern only applies to the single statement portion of the proposal. The proposal also includes a syntax for multi-line scoped code blocks. If you need those in some case, those currently break fluent syntax no matter what.

So what I'm asking for is a more powerful initialization syntax that will (a) provide many of the benefits of fluent style APIs which will also work with any API, and (b) will be able to do things that fluent style APIs cannot do.

[marksmeltzer]

@DavidArno TLDR: that code sample you provided won't compile precisely because the SetValue is not a fluent API.

Over here (#1614 (comment)) I showed a code sample for adding a fluent API wrapper using extension methods. However, that is quite cumbersome to do for every case.

Moreover, there's still the code block use case....

[juliusfriedman]

This also seems like it could be solved by providing an Action or such to the type which needs it, e.g. an Initializable<Typed>(Typed type, Action<Typed> initializer) and then calling that statically where needed, I don't see why all objects should support this concept just so certain syntax's benefit from what seems like is not a highly desired feature and can already be accomplished with a Fluent library design API.

[marksmeltzer]

@juliusfriedman

One of the express goals of the proposal was to eliminate the need to use extension method hacks to achieve inline initialization. Moreover, those delegate calls may not get inlined.

Using explicit static methods (whether local or not), which would have a higher likelihood of being inlined, is even more painful than using delegates.

[marksmeltzer]

@juliusfriedman I certainly wouldn't want to have any such automagic initializer syntax - init logic is almost always contextual.

[vova-lantsov-dev]

#2580 similar proposal

[masums]

Also plesae include event initilization.
Like

return new TextBlock
{
        Width = 172,
        Height = 80,
        TextWrapping = TextWrapping.Wrap,
        Foreground = Brushes.Orange,
        FontFamily = new FontFamily(@"Baskerville Old Face"),
        FontSize = 72,
        Text = "Hello",
        OnTextChanged += (sender, arg) => {
              Console.WriteLine("Text Changed");
         }
}