Proposal: Constructor expression and Object literal

[gulshan]

Background

• In some languages, notably F# and Dart, the keyword new is optional for constructor calls. And in some other languages like Kotlin (and Rust to a certain extent) the new is totally omitted. Omitting new makes long nested constructor call "trees" concise, easy to follow and reason about. Some UI frameworks like Flutter is using these nested constructor calls to build up UI or views, instead of separate UI specific resource files. Not using new makes it concise. This is also similar to Elmish-like view creation.
• Object initializer is a popular way of building objects in C#. But it would not play nice with nullability and immutability that much, which are going to be more featured in future C# versions. So, it can be assumed that constructors will be back to become more prominent in object building business.
• In C#, the something like the new-less constructor expression is already in use- in attribute declarations.

Proposal

This proposal is actually consists of two related proposals-

Constructor expression:

• Syntactically a constructor expression is just a constructor call without the new- like MyObject(id: 1) (while the constructor call being new MyObject(id:1)).
• In C#, new is associated with instantiation and allocation of objects. As per this proposal, unlike constructor calls, a constructor expression will not allocate a new object into the memory. It will create and return an object of the generic value type Constructor<T, TArg1, Targ2, ...>, containing a valid set of constructor call arguments for type T. This constructor object can later be used to create/allocate one or more new objects of type T from the saved arguments.
• Constructor<T> will have a method public T New(). This method will create/allocate an object from the expression and then return it.
• A constructor expression can have nested constructor expressions in the place of their associated typed objects. And when called, New() will call the New() of the children constructor expressions and instantiate them and call the constructor with them. This means, a new T1(new T2(new T3())) constructor call can be coded as T1(T2(T3())).New() with constructor expressions.
• Just like a regular function/constructor call, named parameters and arguments are allowed.

Object literal:

• Syntactically an object literal is a restricted version of constructor expression, which can only contain literals of primitive types or other children object literals For comparison, constructor expressions can contain other variables, expressions, function calls and even constructor calls with new).
• Object literals will be language independent within .net ecosystem.
• Object literals has no special usage in a source code file. When used within a source file, they are just regular constructor expressions. But there can be .net object files (may be with .nobj file extension) containing a single object literal, defining how an object of a certain .net type can be constructed based on one of its constructor. For convenience, .net object files can also contain using statements.
• .net object files can be part of a compilation process, directly recognized by the compiler. Then they can be used in place of other compile time static resource files of different formats like resx, xml, json and even xaml.
• Runtime parsing and validation of object literals (in .net object files) can also be supported. Then they can replace other runtime configuration files. This would not be a general purpose serialization-deserialization replacement though. Because there is no serialization available from an arbitrary .net object to an object literal.
• Object literals can contain list and dictionary literals as described in Proposal: Dictionary Literals #414 .
• Like constructor expressions, named arguments are also allowed in object literals.

Some examples

This is what can be a project file (an example blazor project file taken from web) based on .net object literal project.nobj-

Microsoft.NET.Sdk.Web.Project(
    TargetFramework: Framework.Netstandard20,
    RunCommand: "dotnet",
    RunArguments: "blazor serve",
    LanguageVersion: "7.3",
    Packages: [
        Package("Microsoft.AspNetCore.Blazor.Browser", Version: "0.4.0"),
        Package("Microsoft.AspNetCore.Blazor.Build", Version: "0.4.0"),
        CliTool("Microsoft.AspNetCore.Blazor.Cli", Version: "0.4.0")
    ]
)

Which would be equivalent to current project.csproj-

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <RunCommand>dotnet</RunCommand>
    <RunArguments>blazor serve</RunArguments>
    <LangVersion>7.3</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Browser" Version="0.4.0" />
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="0.4.0" />
    <DotNetCliToolReference Include="Microsoft.AspNetCore.Blazor.Cli" Version="0.4.0" />
  </ItemGroup>
</Project>

This is an attempt to replace a XAML file-

using Microsoft.UI.Components;

Canvas(
    Rectangle(StrokeThickness: 30, RadiusX: 97.5, RadiusY: 97.5,
        Width: 396, Height: 312,
        Fill: LinearGradientBrush(
            StartPoint: (0, 0.5), EndPoint: (1, 0.5),
            GradientStops: [
                GradientStop(Colors.White, Offset: 0),
                GradientStop(Colors.Blue, Offset: 0.5),
                GradientStop(Colors.Black, Offset: 1)
            ]
        ),
        Stroke: LinearGradientBrush(
            StartPoint: (0, 0.5), EndPoint: (1, 0.5),
            GradientStops: [
                GradientStop(Colors.Black, Offset: 0),
                GradientStop(Colors.Red, Offset: 0.5),
                GradientStop(Colors.White, Offset: 1)
            ]
        )
    ),
    Canvas.PositionedElement(    // record type facilitating xaml attached properties
        TextBlock(Width: 172, Height: 80,
            TextWrapping: TextWrapping.Wrap,
            Foreground: Brushes.Orange,
            FontFamily: FontFamily("Baskerville Old Face"),
            FontSize: 72,
            Text: "Hello"
        ),
        Left: 109, Top: 109     // xaml attached properties
    )
)

equivalent to-

<Canvas>
    <Rectangle StrokeThickness="30" RadiusX="97.5" RadiusY="97.5"
    Width="396" Height="312" >
        <Rectangle.Fill>
            <LinearGradientBrush StartPoint="0,0.5" EndPoint="1,0.5">
                <GradientStop Color="White" Offset="0"/>
                <GradientStop Color="Blue" Offset="0.5"/>
                <GradientStop Color="Black" Offset="1"/>
            </LinearGradientBrush>
        </Rectangle.Fill>
        <Rectangle.Stroke>
            <LinearGradientBrush StartPoint="0,0.5" EndPoint="1,0.5">
                <GradientStop Color="Black" Offset="0"/>
                <GradientStop Color="Red" Offset="0.5"/>
                <GradientStop Color="White" Offset="1"/>
            </LinearGradientBrush>
        </Rectangle.Stroke>
    </Rectangle>
    <TextBlock Width="172" Height="80"
        Canvas.Left="109" Canvas.Top="109" TextWrapping="Wrap"
        FontFamily="Baskerville Old Face"
        FontSize="72" Foreground="Orange">
            Hello
    </TextBlock>
</Canvas>

It has to be admitted that XAML has some powerful features added over plain XML and which cannot be easily replicated. This is another attempt to use constructor expressions instead of XAML markup-

public partial class MainPage : ContentPage
{
    Entry phoneNumberEntry;
    Label translatedLabel;
    Button translateButton, callButton;

    string TranslatedText {get; set;}

    void InitializeComponent()
    {
        setPadding(OnPlatform<Padding>(
            iOS: Padding(20, 40, 20, 20),
            Android: Padding(20),
            UWP: Padding(20)
        ).New());

        content = StackLayout(
            Label("Enter a Phoneword:"),
            (phoneNumberEntry = Entry(Text: "1-855-XAMARIN")),
            (translatedLabel = Label(Text: Bind(TranslatedText))),
            (translateButton = Button(Text: "Translate", Clicked: OnTranslate)),
            (callButton = Button(Text: "Call", IsEnabled: false, Clicked: OnCall))
        ).New();
    }
}

equivalent to-

<?xml version="1.0" encoding="UTF-8"?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
                   xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
                   x:Class="Phoneword.MainPage">
    <ContentPage.Padding>
        <OnPlatform x:TypeArguments="Thickness">
            <On Platform="iOS" Value="20, 40, 20, 20" />
            <On Platform="Android, UWP" Value="20" />
        </OnPlatform>
    </ContentPage.Padding>
    <StackLayout>
        <Label Text="Enter a Phoneword:" />
        <Entry x:Name="phoneNumberEntry" Text="1-855-XAMARIN" />
        <Label x:Name="translatedLabel" Text="{Binding TranslatedText}" />
        <Button x:Name="translateButton" Text="Translate" Clicked="OnTranslate" />
        <Button x:Name="callButton" Text="Call" IsEnabled="false" Clicked="OnCall" />
    </StackLayout>
</ContentPage>

Just to note, these are mocks and not working code. And these construction expressions and object literals would be a lot shorter if arguments were not named.

Benefits

• Concise syntax for object construction trees.
• Deferrable object construction, which can be used to reduce GC pressure.
• Constructor expressions can make the allocation of an object tree lumped together and the children objects are not referenced by the calling surface.
• A default format for static/dynamic resource/config files, built into .net ecosystem and based on .net literals.
• Constructor itself can play the role of deserialization in may places.
• Tooling support like intellisense and real-time error squiggles comes from the compiler language service for these .net object files or object literals.

Some open questions

• Should the resultant type of constructor expressions be named ConstructorArguments<T> or CtorArgs<T> instead of Constructor<T>?
• Should "object literals" be named "constructor literals" to reflect it is based on constructors?
• Can there be an implicit operator in Constructor<T> returning T objects? Then just MyClass x = MyClass() would work instantiating the object without calling the New() method- MyClass x = MyClass().New(). To note in this case, var x = MyClass() will still be generating a Constructor<MyClass> object named x inferred from MyClass().

Alternatives

• Just make the keyword new optional in object creation.
• Target-typed new Champion "Target-typed new expression" (VS 16.8, .NET 5) #100 is already being worked on, which offers conciseness of some sort.
• Object literals can be pursued independent of constructor expressions.
• Continue as is, with constructor calls, object initializers and different file formats for compile-time or runtime resources/configurations.

Previously I proposed a .net object notation format based on object initializers on Roslyn repository. This proposal is superseding that one- dotnet/roslyn#16648

[HaloFour]

Why do we need a completely different syntax to accomplish the following?

Func<Project> factory = () => new Microsoft.NET.Sdk.Web.Project {
    TargetFramework = Framework.Netstandard20,
    RunCommand = "dotnet",
    RunArguments = "blazor serve",
    LanguageVersion = "7.3",
    Packages = {
        new Package("Microsoft.AspNetCore.Blazor.Browser") { Version: "0.4.0" },
        new Package("Microsoft.AspNetCore.Blazor.Build") { Version = "0.4.0" },
        new CliTool("Microsoft.AspNetCore.Blazor.Cli") { Version = "0.4.0" }
    }
};

[Mike-E-angelo]

@HaloFour what happens when TargetFramework, RunCommand, RunArguments, and LanguageVersion are not string, struct, or Arrays? If I understand correctly, the ask/idea here is to simplify where new is currently required instantiate a new class, and in your provided example every one of those types are already accounted for by the language to not require the use of new.

Additionally, in the case of the Packages property, the new would be emitted from there, as well, reducing the total amount of required characters by 12, including the white space.

Finally, the ask here (again, if I understand correctly), is to have an implementation that does not require a delegate, which is more cumbersome to create. For instance, you would be able to use var to store/assign the variable, whereas in your example an explicit type is required, unless of course you surround new Func<Project> around the declaration. This is, of course, exactly what this feature request aims to avoid... if I understand correctly. 😄

[HaloFour]

@Mike-EEE

what happens when TargetFramework, RunCommand, RunArguments, and LanguageVersion are not string, struct, or Arrays?

Object initializers don't care what the type is. You can assign any valid expression to any writable property.

the ask/idea here is to simplify where new is currently required instantiate a new class, and in your provided example every one of those types are already accounted for by the language to not require the use of new.

I don't see why this is a good thing. You're creating instances of classes and that uses the new operator in C#. That's not boilerplate, that's intent. The short-hand for object creation expressions will be to omit the type name, not the operator.

I also want to say that I've seen proposals seeking to allow omitting new from object creating expressions and that they were not positively received, but my search-fu is failing me.

Finally, the ask here (again, if I understand correctly), is to have an implementation that does not require a delegate, which is more cumbersome to create.

Having to name the type is not cumbersome. You'll be required to do that if you plan on assigning it to a field or passing it as an argument to a function anyway.

And frankly I don't see why you'd tie some alternative construction syntax with factory generation. Those concerns are entirely orthogonal. And both are solved just fine by the language today.

It's generally considered a bad idea to have two ways of expressing the exact same thing, especially when the only real benefit is very slight savings in the number of overall characters.

[ufcpp]

#350

[gulshan]

@HaloFour With object literals, I am actually proposing a json-like format, for object creation. Object literals are language independent but .net platform dependent. Parsing object literals will be supported by BCL or nuget library at runtime, when the compiler is not present. To parse an .nobj file, one would not have to invoke the language compiler. So, existing syntax is not relevant is that case.

Another point is, object initializes does not play nice with immutable properties. And the class/type designer has little control over the initialization. But constructors give the designer full control.

I have tried to mention these points in the main proposal also. It is a bit lengthy to read though.

[yaakov-h]

Can't you just use using static to achieve the code style you want today?

For example, I can do the following using the Roslyn APIs to construct a method call, with a using static in scope:

ExpressionStatement(
    InvocationExpression(
        MemberAccessExpression(
            SyntaxKind.SimpleMemberAccessExpression,
            MemberAccessExpression(
                SyntaxKind.SimpleMemberAccessExpression,
                IdentifierName("System"),
                IdentifierName("Console")),
            IdentifierName("WriteLine")))
    .WithArgumentList(
        ArgumentList(
            SingletonSeparatedList<ArgumentSyntax>(
                Argument(
                    LiteralExpression(
                        SyntaxKind.StringLiteralExpression,
                        Literal("Hello World")))))))

Also, your object literals proposal sounds more like blittable (#187) constants, which has come up in a few different discussions, but I don't think it has a proposal of it's own.

[svick]

The thing that I don't understand about this proposal is the need for Constructor<T>. Isn't it pretty much the same thing as Func<T>, only with a confusing syntax? (It's a constructor expression, but it doesn't actually call the constructor?)

You say that deferring object construction like this can reduce GC pressure. Can you explain how exactly would that be achieved, especially compared with deferring using a lambda and Func<T> that's already possible?

[svick]

@gulshan

Parsing object literals will be supported by BCL or nuget library at runtime, when the compiler is not present. To parse an .nobj file, one would not have to invoke the language compiler.

You can already do that today using the Microsoft.CodeAnalysis.CSharp.Scripting package. I'm not sure parsing your .nobj files would be significantly more efficient than that, at least assuming you want to make sure every object literal does the same thing as when you treat it as constructor expression.

For example, I think .nobj parser would pretty much have to include all of Roslyn's binding logic (the part of the compiler that determines that the MyObject string represents the MyNamespace.MyObject type).

[gulshan]

@svick Constructor expression was the focus of the proposal. Type is a part of that. I think if a feature like constructor expression is implemented, a specially designed type like Constructor<T> with focus on constructor expression focused functionalities would be better than a general purpose type like Func<T>. And then this new type can be designed to be light on allocation. A simple part of that can be making it a value type, as proposed here. Regarding confusing syntax, it is subjective IMHO. As I have mentioned, new is optional in languages like F# and Dart. Some other languages like Kotlin totally abandoned new in constructors. Which made the constructor calls concise. Proposed constructor expression is somewhat of a middle ground between making new optional and current mandatory state. And the implicit operator from constructor expression to target types can increase or decrease the confusion, subjectively.

Regarding object literals, as it is based on language syntax, a subset of the language parser aka Roslyn has to be used to parse them in runtime. If targeted, it can be very minimal in my opinion. Regarding, type resolution of the object literals, I think in the runtime, the type should not be resolved solely based on the literal or the nobj file. Rather parser will take a type argument and will try to validate the object literal against its constructors. The using statements will be useful for tooling purpose while hand-editing the .nobj files. This was not in my mind during the proposal though. After seeing your comment, it came to me.

I would like to make one more point. This proposal does not enable anything new, which is not already possible now. This is proposal is about convenience. So, comments like "you can already do this using so and so" are all mostly true. But that's not the point. The point is whether assumed convenience is worth the implementation cost (in some near or distant future).

[HaloFour]

@gulshan

I think if a feature like constructor expression is implemented, a specially designed type like Constructor with focus on constructor expression focused functionalities would be better than a general purpose type like Func. And then this new type can be designed to be light on allocation. A simple part of that can be making it a value type, as proposed here.

If you don't like the name Func<T> then fine:

public delegate T Constructor<T>();

As for it being a value type, I don't get how you imagine that would work. Are you expecting the BCL to add yet another completely new expression tree API built on structs?

This is proposal is about convenience. So, comments like "you can already do this using so and so" are all mostly true. But that's not the point. The point is whether assumed convenience is worth the implementation cost (in some near or distant future).

That is the point. It's not convenient to have two almost identical flavors of syntax to accomplish the same task in the language. Preferring to omit new in some places because some other languages allow for it, or alternating between colons and equals signs, is purely stylistic. C# isn't F# or Dart.

[svick]

@gulshan

I think if a feature like constructor expression is implemented, a specially designed type like Constructor<T> with focus on constructor expression focused functionalities would be better than a general purpose type like Func<T>.

What kind of functionalities? So far, the only difference between Func<T> and Constructor<T> is in naming.

And then this new type can be designed to be light on allocation. A simple part of that can be making it a value type, as proposed here.

It's not clear to me how that would be an improvement. Today, if I write e.g. Func<Foo> func = () => new Foo();, then it allocates a single delegate over the lifetime of the application. So Constructor<T> is not going to be significantly better in that case.

Lambdas can allocate a lot when they close over local variables, but Constructor<T> would also have to store that data somewhere.

Regarding confusing syntax, it is subjective IMHO. As I have mentioned, new is optional in languages like F# and Dart. Some other languages like Kotlin totally abandoned new in constructors. Which made the constructor calls concise. Proposed constructor expression is somewhat of a middle ground between making new optional and current mandatory state. And the implicit operator from constructor expression to target types can increase or decrease the confusion, subjectively.

I think it's more than a subjective opinion and that a lot of people would find it confusing that the syntax that's promoted as "you can now avoid typing new, like in those other languages" actually wouldn't construct an instance of the type if you write e.g. var foo = Foo();. And there are many other cases where implicit operators wouldn't help, like: names.Select(name => Person(name)).

[gulshan]

I wish, subjective things remain subjective and open for discussion. I also wish there are choices, if it is not obviously/objectively bad.

I don't think Constructor<T> should be a delegate either. It's main purpose is storing constructor arguments, not the expression itself. It's more like Constructor<T, TArg1, TArg2, … >. Things are becoming clearer through discussion. So, it should not be called ConstructorExpression<T>. Should it be called ConstructorArguments<T> then?

This feature should never be promoted as "you can avoid typing new like other languages". The promotion would be something like- "if you have lot's on new in a single expression, then now you can write it just once, at the end, with .New(). Or you can defer it." I myself am skeptical about the implicit operator and thus kept it open in the proposal.

[marksmeltzer]

I love the concept of being able to do XAML like things from code -- that is describe an entire object builder pipeline without actually allocating those objects. I'm not sure if the current proposal would work though.

XAML does its magic by having readers and writers, and having plumbed the depths of the XAML source code, the logic is quite complex. To replicate a similar function with a concise C# syntax, a lot of the analogous parsing logic would have to be recreated or borrowed. For instance, there's specific syntax handling of handling arrays, lists, dictionaries, let alone all of the known supported types.

It isn't a trivial thing to be able to populate a list or dictionary with members via XAML -- support for that was explicitly baked in, and that code is rather brittle when it comes to user defined types.

I have built my own custom XAML parsing to handle cases that the stock parser cannot handle, and I'll tell you that it is very brittle and cumbersome. It's one of those, "I have a problem. Ah hah, I know what to do: I'll use XAML to solve it! Crap. Now I have two problems." type situations. While the library I built is extremely robust and powerful, it has also been a continual thorn in my side since it has required regular routine maintenance over the years to add explicit support for new scenarios where some developer tried doing something seemingly trivial that didn't work since it involved some new data type or collection type or some unsupported construction scenario.

Speaking of construction scenarios, if something like this ever came to be, we would definitely need it to support factory methods and builders.

My current thought is that something like this could be achieved using something like Lambdas expressions, which also support compilation. Am I missing something vital?

Here's a working sample using today's C#:

    public static class XamlHelpers
    {
        public static T FluentSetValue<T>( this T target, DependencyProperty property, object value )
            where T : DependencyObject
        {
            target.SetValue( property, value );
            return target;
        }
    }
...

        public void Test( )
        {
            Expression<Func<Canvas>> factoryExpression = ( ) => new Canvas
            {
                Children =
                {
                    new Rectangle
                    {
                        StrokeThickness = 30,
                        RadiusX = 97.5,
                        RadiusY = 97.5,
                        Width = 396,
                        Height = 312,
                        Fill = new LinearGradientBrush
                        {
                            StartPoint = new Point( 0, 0.5 ),
                            EndPoint = new Point( 1, 0.5 ),
                            GradientStops = new GradientStopCollection
                            {
                                new GradientStop( Colors.White, 0 ),
                                new GradientStop( Colors.Blue, 0.5 ),
                                new GradientStop( Colors.Black, 1 )
                            }
                        },
                        Stroke = new LinearGradientBrush
                        {
                            StartPoint = new Point( 0, 0.5 ),
                            EndPoint = new Point( 1, 0.5 ),
                            GradientStops = new GradientStopCollection
                            {
                                new GradientStop( Colors.Black, 0 ),
                                new GradientStop( Colors.Red, 0.5 ),
                                new GradientStop( Colors.White, 1 )
                            }
                        }
                    },
                    new TextBlock
                        {
                            Width = 172,
                            Height = 80,
                            TextWrapping = TextWrapping.Wrap,
                            Foreground = Brushes.Orange,
                            FontFamily = new FontFamily( @"Baskerville Old Face" ),
                            FontSize = 72,
                            Text = "Hello"
                        }.FluentSetValue( Canvas.LeftProperty, 109 )
                         .FluentSetValue( Canvas.TopProperty, 109 )
                }
            };

            Func<Canvas> factory = factoryExpression.Compile( );

            Canvas canvas = factory( );
        }

Having the C# compiler compress all that XAML specific cruft down to the sample from the original proposal would require making the C# compiler very away of a lot of XAML specific constructs, which wouldn't be advisable.

However, having the C# compiler use Lamdas expressions and have a syntax for simplying the code from Test() above into something more manageable could be a nice addition. Preferably the expression above could be modified to accept some parameters as well to allow it to behave like a parameterized factory method.

[marksmeltzer]

Would there be a huge benefit if the C# compiler could handle this code which removes the calls to new? I see the economy of the saved keystrokes, but I'm not sure if would be worth the effort.

        public void Test( )
        {
            Factory<Canvas> factory = ( ) => Canvas
            {
                Children =
                {
                    Rectangle
                    {
                        StrokeThickness = 30,
                        RadiusX = 97.5,
                        RadiusY = 97.5,
                        Width = 396,
                        Height = 312,
                        Fill = LinearGradientBrush
                        {
                            StartPoint = Point( 0, 0.5 ),
                            EndPoint = Point( 1, 0.5 ),
                            GradientStops = GradientStopCollection
                            {
                                GradientStop( Colors.White, 0 ),
                                GradientStop( Colors.Blue, 0.5 ),
                                GradientStop( Colors.Black, 1 )
                            }
                        },
                        Stroke = LinearGradientBrush
                        {
                            StartPoint = Point( 0, 0.5 ),
                            EndPoint = Point( 1, 0.5 ),
                            GradientStops = GradientStopCollection
                            {
                                GradientStop( Colors.Black, 0 ),
                                GradientStop( Colors.Red, 0.5 ),
                                GradientStop( Colors.White, 1 )
                            }
                        }
                    },
                    TextBlock
                        {
                            Width = 172,
                            Height = 80,
                            TextWrapping = TextWrapping.Wrap,
                            Foreground = Brushes.Orange,
                            FontFamily = FontFamily( @"Baskerville Old Face" ),
                            FontSize = 72,
                            Text = "Hello"
                        }.FluentSetValue( Canvas.LeftProperty, 109 )
                         .FluentSetValue( Canvas.TopProperty, 109 )
                }
            };

            Canvas canvas = factory.New( );
        }

[marksmeltzer]

Such logic would also benefit from having another helper like this so that objects could be initialized inline with arbitrary logic as needed. Problem is that this extension method would be visible everywhere... But some special by-ref syntax sugar could eliminate this need for this extension method to actually be declared in any public API by exposing some specific keywords or grammar to achieve the same effect and have the action logic compiled inline.

        public delegate void FluentWithDelegate<T>( ref T target );

        public static T FluentWith<T>( this T target, FluentWithDelegate<T> action )
        {
            action( ref target );
            return target;
        }

[marksmeltzer]

Using the concept above, maybe something like this could work -- which is simply adding the ability to call a method that looks like it is implemented inline using this to refer to the instance being initialized:

        public void Test( )
        {
            Factory<Canvas> factory = ( ) => Canvas
            {
                Children =
                {
                    Rectangle
                    {
                        StrokeThickness = 30,
                        RadiusX = 97.5,
                        RadiusY = 97.5,
                        Width = 396,
                        Height = 312,
                        Fill = LinearGradientBrush
                        {
                            StartPoint = Point( 0, 0.5 ),
                            EndPoint = Point( 1, 0.5 ),
                            GradientStops = GradientStopCollection
                            {
                                GradientStop( Colors.White, 0 ),
                                GradientStop( Colors.Blue, 0.5 ),
                                GradientStop( Colors.Black, 1 )
                            }
                        },
                        Stroke = LinearGradientBrush
                        {
                            StartPoint = Point( 0, 0.5 ),
                            EndPoint = Point( 1, 0.5 ),
                            GradientStops = GradientStopCollection
                            {
                                GradientStop( Colors.Black, 0 ),
                                GradientStop( Colors.Red, 0.5 ),
                                GradientStop( Colors.White, 1 )
                            }
                        }
                    },
                    TextBlock
                        {
                            Width = 172,
                            Height = 80,
                            TextWrapping = TextWrapping.Wrap,
                            Foreground = Brushes.Orange,
                            FontFamily = FontFamily( @"Baskerville Old Face" ),
                            FontSize = 72,
                            Text = "Hello",
                            {
                              this.SetValue( Canvas.LeftProperty, 109 );
                              this.SetValue( Canvas.TopProperty, 109 );
                            }
                        }
                }
            };

            Canvas canvas = factory.New( );
        }

[Mike-E-angelo]

@marksmeltzer perhaps a new keyword altogether rather than this? Technically this isn't available/instantiated yet by the time that is evaluated (if I understand correctly).

[marksmeltzer]

@Mike-EEE

I've just submitted a proposal #2556 to add the initialization syntax described above to support arbitrary code execution in instance initializers.