Allow both collection and property initializer

[michaelcheers]

See:
https://stackoverflow.com/questions/7647097/possible-to-mix-object-initializer-and-collection-initializer

Why is this not allowed?
I believe this would not be a breaking change.

This could be useful for example in html generation.
Currently, a Children property has to be added.

new HTMLDivElement
{
    Width="100%",
    Height="100%",
    new HTMLSpanElement { Style = { FontColor = "red"}, "Span 1" },
    new HTMLSpanElement { Style = { FontColor = "blue"}, "Span 2" },
}

instead of

new HTMLDivElement
{
    Width="100%",
    Height="100%",
    Children =
    {
        new HTMLSpanElement
        {
            Style = { FontColor = "red"},
            Children = { "Span 1"  }
        },
        new HTMLSpanElement
        {
            Style = { FontColor = "blue"},
            Children = { "Span 2"  }
        },
    }
}

<div width="100%" height="100%">
    <span font-color="red">Span 1</span>
    <span font-color="blue">Span 2</span>
</div>

[jnm2]

How would the compiler know to use the collection property Children? What if there are multiple collection properties?

Edit: Sorry, I missed the implication of "Currently, a Children property has to be added."

[HaloFour]

I think the proposal is to allow the collection initializer without having to declare a Children property on the type, it would call an Add method on the initialized object directly:

var foo = new Foo { Prop1 = "Value", 2, 3, 4 };

// equivalent to
var $temp = new Foo();
$temp.Prop1 = "Value";
$temp.Add(2);
$temp.Add(3);
$temp.Add(4);
var foo = $temp;

My concern would be whether you can mix object, collection (and presumably indexer) within the initializer in any order and whether that would be reasonable readable:

var foo = new Foo {
    Prop1 = "Value1",
    2,
    3,
    ["fizz"] = "buzz",
    4,
    Prop2 = "Value2"
};

[jnm2]

I've been wanting this for a while, too. I think it's visually easy to separate the difference between expr, [index] = expr, and Member = expr, and the compiler also won't get confused between them. (If you want to use the highly unusual syntax SomeVariable = expr as a collection item, you already have to wrap it with parentheses.)

[TahirAhmadov]

I also need this and I'm sure all UI developers out there will agree, too.
We can limit it to collection items have to come after member setters.

[CyrusNajmabadi]

I think there's a lot of merit in this. And i'm willing to champion this.

[TahirAhmadov]

@CyrusNajmabadi I know everybody is busy, but I wanted to bump this request. Have you had a chance to look into it?

[CyrusNajmabadi]

Championed issue here: #10185

[TahirAhmadov]

Perhaps after last member setter, we can have an ;, then whatever comes after it is treated as collection items?

new HTMLDivElement
{
    Width="100%",
    Height="100%"; // last member setter
    new HTMLSpanElement { Style = { FontColor = "red"}, "Span 1" },
    new HTMLSpanElement { Style = { FontColor = "blue"}, "Span 2" },
}

Unless it's not needed and compiler can deduce this automatically. Come to think of it, if you encounter an identifier and =, then it's a member setter, otherwise parse expression and look for collection adder. If you need to add an item and assign a variable in one, wrap in ().

[MadL1me]

The problem I have with this, is that we may have a >1 collections in a class, with same type:

Let's see at this example:

public class User
{
    public int Name { get; private set; }   

    public ICollection<User> Relatives { get; private set; }

    public ICollection<User> Friends { get; private set; }
}

new User() 
{
    Name = "Alexandra",
    new User() { Name = "Albert" },  // Now, how we supposed to distinguish who goes to "Relatives" and who goes to "Friends"?
    new User() { Name = "John" }
}

Yeah, situations like this (when we have 2 collections of same types in class) is not that frequent. However, if we have such case, it seems to me, that this feature will only bring more confusion. Yes, we can enable this feature only if we have only 1 collection with unique type in class, but it stills feels not right to me.

[TahirAhmadov]

That's not how it works. Please refer to https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers#collection-initializers

Collection initializers let you specify one or more element initializers when you initialize a collection type that implements IEnumerable and has Add with the appropriate signature as an instance method or an extension method. The element initializers can be a simple value, an expression, or an object initializer. By using a collection initializer, you do not have to specify multiple calls; the compiler adds the calls automatically.

The user class itself has to implement IEnumerable and have Add method(s); it's not looking for properties of collection types.

[MadL1me]

I understand that, but this doesn't seem to help. I can change ICollection to IEnumerator, and the issue still will be there: how compiler knows which instance should be added to which property?

[TahirAhmadov]

Read again:

The User class itself has to implement IEnumerable and have Add method(s); it's not looking for properties of collection types.

[jnm2]

@MadL1me The proposal is that user.Add is what gets called, not user.Relatives.Add or user.Friends.Add.

[MadL1me]

@jnm2 oh, I get it, thanks

[CyrusNajmabadi]

I have opened a proposal and official discussion thread for this:

• Proposal: https://github.com/dotnet/csharplang/blob/main/proposals/mixed-object-and-collection-initializers.md (PR Mixed object and collection initializers: initial proposal #10184)
• Championing issue: [Proposal]: Mixed object and collection initializers #10185
• Official discussion: [Proposal]: Mixed object and collection initializers #10186

Please move further conversation to #10186 so it can feed directly into the LDM review of the proposal. Thanks!