Proposal: Brace type initializers

[jkone27]

I guess it would be nice if new operator could be optionally avoided (when possible) in favour of object initialization in the c++ 11/14 style, something like..

  SomeType r1 {15, "something", 0 };  //brace initializer (1)

  SomeType r2(12, "hello") ;          //inline initializer (2)

http://www.stroustrup.com/C++11FAQ.html#uniform-init

msdn initialization

c++ initialization

is this doable or any useful at all, what do you think?

EDIT:

• brace initializer (1) is used for collections already, though it could be extended to other types too (like C++ does, in favour of less typing),
• inline initializer (2) could be used for records types (immutable pocos)

EDIT 2 (for better clarity):

let's start with an immutable type (sealed poco class with only get methods)

public sealed class Name {

    public string FirstName { get; }
    public string LastName { get; }

    public Name(string first, string last) {
            FirstName = first;
            LastName = last;
    }

}

proposed changes would make possible to turn this "old" one (just an example class, sorry if it's not too clear) ...

public class Kitty {

    private readonly Name _kitty;
    public IEnumerable<Name> Childs {get; } 
    public string[] Meows {"meow","meowwww","miao"} { get; } //privately mutable
    public string Color { get; }

    public Kitty(Name kitty, string color = null) {
           _kitty = kitty;
           Childs = new List<Name>();
           Color = color??"white";
    }

   public Kitty Make(Name kitty){
         Childs.Add(kitty);
         return new Kitty(kitty);
   }

}

into this "new one"...
please notice the use of member initializer list which is now made possible

public class Kitty {

    private readonly Name _kitty;
    public  List<Name> Childs{ } { get; } //privately mutable 
    public string[] Meows {"meow","meowwww","miao"} { get; } //privately mutable
    public string Color { get; }

    public Kitty(Name kitty, string color = null) :
         _kitty(kitty), Color(color??"white") {  } //Name is immutable, and also Color is immutable!(is a string)

   public Kitty Make(Name kitty){
         Childs.Add(kitty);
         return Kitty{kitty}; //no need for new (Kitty is mutable, not sealed, plus Make is not thread safe.)
   }

}

How does it feel?

[svick]

Why? What's the advantage? Just saving some typing?

[jkone27]

One possible improvement could be to distinguish the creation of immutable object (sealed poco class with get and private set only) vs mutable objects.

Type { }; could be used for mutable (collections initializer form)
Type ( ); for immutable

In F# the { } construct is used to declare and instantiate Record Types, though in a different manner..

and yes, the other minor advantage would be less "new" around the code,
but it would stick around of course when saying : var x = new Something(...);

[svick]

Except C# already distinguishes the two types of braces when creating objects for completely different purpose:

• new List<int> { 10 } creates a new List<int> using the parameterless constructor and then adds 10 to it
• new List<int>(10) creates a new List<int> using the int constructor (which is used to specify initial capacity)

I don't think adding a new syntax for creating objects where the two types of braces have a completely different meaning (and one that is not enforced at that) would be a good idea.

[aluanhaddad]

I love C++11 initializers but I normally write them as

auto r1 = SomeType { 15, "a parameter", "another parameter", 0 };

because it makes for nicely regular alignment.

That said, one of the primary reasons for the introduction of uniform initialization syntax in C++ was to improve type safety of construction. This isn't an issue in C#.

As for new, I can understand wanting to elide it, but there are other ways to achieve this, for example factories + using static.

One possible improvement could be to distinguish the creation of immutable object (sealed poco class with get and private set only) vs mutable objects.

Type { }; could be used for immutable and
Type ( ); for mutable, or the other way around (just a convention)

This proposal won't help here because immutable pocos can already be constructed with constructors and factories. The desire for immutable initializers is to combine the significant readability benefits of C# object initializers without requiring public set or internal set.

[aluanhaddad]

To clarify, I think that what C# needs in this area is

var p = new Person
{ 
    Name = "John",
    Age = 12
}

where Person.Name and Person.Age are readonly.

[HaloFour]

We already have:

var p = new Person
(
    Name: "John",
    Age: 12
);

Records will encourage this approach.

[jkone27]

@svick , @aluanhaddad Since @HaloFour cited the record feature, there's now no more mismatch with collections initializers.
I edit my post in favour of ( ) for immutable.

[dsaf]

#229

[jkone27]

please see my EDIT 2 at the original proposal, for better clarification of what I think may be useful.