Allow Object Initializer to Support Both Properties and Children

[hollyschilling]

Currently in C#, an object initializer may contain properties or children, as in either of these cases:

var list = new List<string>
{
    "First",
    "Second",
    "Third"
};

var pet = new Pet
{
    Name = "Bingo",
    Species = Species.Dog,
    BirthDate = new DateTime(2008, 5, 1, 8, 30, 52)
};

In modern UI code, it is common to have objects that have children and values to be set on them. For example, a StackLayout in Xamarin.Forms may have a BackgroundColor, Orientation, and a HeightRequest, in addition to its child views added to it. Currently, the only way to achieve this is through writing the code procedurally, such as:

var stack1 = new StackLayout
{
    Orientation = StackOrientation.Horizontal,
    BackgroundColor = Color. Fuchsia,
};
stack1.Add(new Label { Text = "First" });
stack1.Add(new Label { Text = "Second" });

// Or

var stack2 = new StackLayout
{
    new Label { Text = "First" },
    new Label { Text = "Second" }
};
stack2.Orientation = StackOrientation.Horizontal;
stack2.BackgroundColor = Color. Fuchsia;

What I propose is that the syntax should be able to handle both, as the following:

var stack = new StackLayout
{
    Orientation = StackOrientation.Horizontal,
    BackgroundColor = Color. Fuchsia,
    new Label { Text = "First" },
    new Label { Text = "Second" }
};

This is a natural extension of the current functionality and should be fairly simple to implement. The only issue I could imagine is potential conflicts in cases of scope collisions.

public class Foo {
    public View Header { get; set; }
    public void Add(View child) { ... }
}

public class Bar {
    private View Header { get; set; }
    public void Demonstration()
    {
        var foo = new Foo
        {
            Header = new Label { Text = "Where does this go?" } 
        };
    }
}

In this example, Header = new Label { Text = "Where does this go?" } could be intended to assign to the property on Foo or on Bar. If it is intended to assign to the property on Foo, it would trigger the normal property setter on Foo and ignore the property setter on Bar. If it instead were intended to assign to the property on Bar, it would trigger the property setter on Bar and then trigger the Add method on Foo due to the associativity of the assignment operator. Even now, I'm not quite sure how C# 9 resolves this conflict.

Since this is not a new problem and already has defined behavior, I do not see this as an impediment to implementation of this change.

[HaloFour]

var stack1 = new StackLayout
{
    Orientation = StackOrientation.Horizontal,
    BackgroundColor = Color. Fuchsia,
    Children = {
        new Label { Text = "First" },
        new Label { Text = "Second" }
    }
};

[hollyschilling]

I'm aware that in that case there is a work around, but not all cases have such a work around. There is no reason the language cannot support both.

[HaloFour]

I've not seen a fluent UI API that hasn't offered a child collection property. Do you know of other specific use cases that cannot be solved using existing language features?

[hollyschilling]

The case that got me started on this is UIKit’s UIView. It had cannot set Subviews from the initializer, but it does support Add to in-line the children during the initialization. I believe there are a few others within Xamarin and Xamarin Forms, but I can’t think of them at this moment.

Even if the use case is small, it seems odd that the language already doesn’t have this ability. There doesn’t seem to be any reasons it can’t exist.

Similarly, the dictionary literal notation [“Foo”] = “Bar” seems as though it should be able to be included as well. I don’t have a good use case for it, but I’m sure someone will find one.

[theunrepentantgeek]

Even if the use case is small, it seems odd that the language already doesn’t have this ability.
There doesn’t seem to be any reasons it can’t exist.

Features need to have significant benefits to justify the investment in time to specify, develop, test, and maintain them.

Eric Gunnerson used to be on the C# team and he summarized it will by saying

Every feature starts out in the hole by 100 points, which means that it has to have a significant net positive effect on the overall package for it to make it into the language. Some features are okay features for a language to have, they just aren't quite good enough to make it into the language.

His original blog post is insightful.