New keyword { get; set; init; }

[srburton]

This proposal comes to make the code cleaner since get and set came to help us programmers. I believe init will make the code less polluted when we need to initialize many properties, avoiding the famous NullPointerException.
I think the good use of the technique will make the code look better.

Today:

public class Abc
{ 
  public List<string> Property {get; set;}   
 
  public Abc(){
    Property = new List<string();
  }
}

Solution:

public class Abc
{ 
  public List<string> Property {get; set; init; }   
}

[Joe4evr]

Why not simply use public List<string> Property {get; set;} = new List<string>();?

[YairHalberstadt]

With target typed new, this becomes:

public List<string> Property {get; set;} = new(); which is two characters longer.

[theunrepentantgeek]

How is this superior to this:

public class Abc
{ 
  public List<string> Property {get; set;} = new();
}

Target Typed new has already been proposed.

[srburton]

superior to this:

Superior in terms of beauty and functionality eg:

public class Abc
{ 
  public List<string> Property {
        get;
        set;  
        init {
            value.add("Apple");
        } 
      }
}

[srburton]

Why not simply use public List<string> Property {get; set;} = new List<string>();?

We do not think of a code with many properties, as we can see below.

Ugly example:

public class Abc
{ 
    public List<string> Property {get; set;} = new List<string>();
    public List<string> Property2 {get; set;} = new List<string>();
    public List<string> Property3 {get; set;} = new List<string>();
    public List<string> Property4 {get; set;} = new List<string>();
    public List<string> Property5 {get; set;} = new List<string>();
    public List<string> Property6 {get; set;} = new List<string>();
    public List<string> Property7 {get; set;} = new List<string>();
    public List<string> Property8 {get; set;} = new List<string>();
    public List<string> Property9 {get; set;} = new List<string>();
    public List<string> Property10 {get; set;} = new List<string>();
    public List<string> Property11 {get; set;} = new List<string>();
    public List<string> Property12 {get; set;} = new List<string>();
    public List<string> Property13 {get; set;} = new List<string>();
    public List<string> Property14 {get; set;} = new List<string>();

}

Beautiful example:

public class Abc
{ 
    public List<string> Property {get; set; init; }
    public List<string> Property2  {get; set; init; }
    public List<string> Property3  {get; set; init; }
    public List<string> Property4  {get; set; init; }
    public List<string> Property5  {get; set; init; }
    public List<string> Property6  {get; set; init; }
    public List<string> Property7  {get; set; init; }
    public List<string> Property8  {get; set; init; }
    public List<string> Property9  {get; set; init; }
    public List<string> Property10 {get; set; init; }
    public List<string> Property11 {get; set; init; }
    public List<string> Property12  {get; set; init; }
    public List<string> Property13  {get; set; init; }
    public List<string> Property14  {get; set; init; }

}

[HaloFour]

Why do you expect an init block without an implementation to invoke a default constructor, or any constructor? I don't see why your code wouldn't also produce a NullReferenceException.

[srburton]

Why do you expect an init block without an implementation to invoke a default constructor, or any constructor? I don't see why your code wouldn't also produce a NullReferenceException.

I think the infinite would be an embellishment of language.

In the NullReferenceException case we imagine the following scenario:

Example NullReferenceException

public class Abc
{ 
    public List<string> Property {get; set; }
}

public class Cba
{
       
    public Cba()
    {
          var abc = new Abc();
          abc.Property.Add("Apple");
    }
}

Solution Ugly

public class Abc
{ 
    public List<string> Property {get; set; } = new List<string>();
}

public class Cba
{
       
    public Cba()
    {
          var abc = new Abc();
          abc.Property.Add("Apple");
    }
}

Example beautiful

public class Abc
{ 
    public List<string> Property {get; set; init; }
}

public class Cba
{
       
    public Cba()
    {
          var abc = new Abc();
          abc.Property.Add("Apple");
    }
}

[HaloFour]

That doesn't answer any of my questions/concerns. Why should this init "block"-like thing somehow cause a new instance to be created? And why do we need a new syntax at all when we already have a syntax for initializing an auto-property to a value? You thinking that the existing syntax is "ugly" is not a good reason to add redundant syntax.

[srburton]

How is this superior to this:

public class Abc
{ 
  public List<string> Property {get; set;} = new();
}

Target Typed new has already been proposed.

The init keyword is also superior because it is only instantiated when called
In your case when new List <string> is called it is already in memory, the keyword init will only enter memory when called.

[srburton]

That doesn't answer any of my questions/concerns. Why should this init "block"-like thing somehow cause a new instance to be created? And why do we need a new syntax at all when we already have a syntax for initializing an auto-property to a value? You thinking that the existing syntax is "ugly" is not a good reason to add redundant syntax.

Reply:

The init keyword is also superior because it is only instantiated when called
In your case when new List is called it is already in memory, the keyword init will only enter memory when called.

[CyrusNajmabadi]

the keyword init will only enter memory when called.

What are the mechanics by which that woulf work?

[HaloFour]

@srburton

So then this is a duplicate of the various "lazy" property proposals already on this repo. And it also falls to the same problem as those proposals, namely that threading and publishing policy now become concerns.

[CyrusNajmabadi]

value.add("Apple");

... } = new List<string> { "Apple" };

[srburton]

The question I want to raise here is today property calls are very brown in time
In current software, problems with NullReferenceException are not interesting the init keyword will make the code cleaner much easier to understand.

Keyword init working

init will only be executed when the property has a complex object with constructor.

Requirements:

• Be a complex object
• be null

Success

public class Abc
{
   public List<string> Property  { get; set; init; }
   public Abc Property2  { get; set; init; }
}

Fail

public class Abc
{
   //Fail
   public decimal Property  { get; set; init; }
   //Fail
   public string Property2  { get; set; init; }
   // Fail
   public double Property3  { get; set; init; }
}

Save the memory

In this example I will show when the keyword init comes into action.

public class Abc
{
   public List<string> Property  { get; set; init; }
   public Abc Property2  { get; set; init; }
}
  
public class Cba
{
    public Cba()
    {
         var cba = new Abc();
          
          // The init keyword kicks in this part, it checks if the property is null
         // if null it will automatically do the new List <string> ()
         cba.Property.Add("Apple");
    }
}

[HaloFour]

I don't find that code at all easier to understand, especially given it doesn't remotely describe what it's going to do, or when, or what happens in the myriad of edge cases that will arise, such as when multiple threads attempt to access the property, or if you explicitly attempt to assign null.

[srburton]

I don't find that code at all easier to understand, especially given it doesn't remotely describe what it's going to do, or when, or what happens in the myriad of edge cases that will arise, such as when multiple threads attempt to access the property, or if you explicitly attempt to assign null.

Save the memory

In this example I will show when the keyword init comes into action.

public class Abc
{
   public List<string> Property  { get; set; init; }
   public Abc Property2  { get; set; init; }
}
  
public class Cba
{
    public Cba()
    {
         var cba = new Abc();
          
          // The init keyword kicks in this part, it checks if the property is null
         // if null it will automatically do the new List <string> ()
         cba.Property.Add("Apple");
    }
}

[HaloFour]

So, that means that every single access of the property has to do a null check? And it's impossible to set the property to null explicitly? And that read-only properties cannot be init? And that if two threads attempt to access the property concurrently that they will end up overwriting each other's instance?

[theunrepentantgeek]

The question I want to raise here is today property calls are very brown in time

This isn't an idiom I've ever heard before - can you please explain?

[srburton]

So, that means that every single access of the property has to do a null check?
R: Yes, Only when you have the init keyword, in the absence of the init keyword will the process continue as normal.

And it's impossible to set the property to null explicitly?
R: Yes, Only when you have the init keyword, in the absence of the init keyword will the process continue as normal.

And that read-only properties cannot be init?
R: When the property is readonly automatically the init keyword will take action, not expecting an explicit call.

Example success:

public class Abc
{
  private readonly List<string> _property { get; set; init; }
 
 public  readonly List<string> Property1 { get; set; init; }

   public void Add()
   {
      _property.Add("Apple");
      Property1.Add("Dog");
   }
}

And what if two threads attempt to access the property concurrently that they will end up overwriting each other's instance?
R: Interesting your reasoning had not thought of this possibility, I will think better about the proposal.

[DavidArno]

Superior in terms of beauty and functionality eg:

Beauty clearly is in the eye of the beholder here. Your code example,

public class Abc
{ 
  public List<string> Property {
        get;
        set;  
        init {
            value.add("Apple");
        } 
      }
}

is certainly not beautiful in my view. You aren't following the common C# brace style convention, and the code is long and rambling, so is far from beautiful. And as others have told you, target typed-new is proposed for a future language version, and so you code example possibly could then be expressed as:

public class Abc
{ 
  public List<string> Property { get; set; } = new { "Apple" };  
}

which is far superior in my view. Others may disagree though as the subject of code beauty is so subjective.

I therefore see no benefit to this proposal.

[svick]

@DavidArno Tiny correction: based on the proposal, I believe the syntax would have to be:

public List<string> Property { get; set; } = new() { "Apple" };  

Though that doesn't change anything about what you said.

[pie-flavor]

You say beauty, I say clarity. With new(), I know exactly what is meant; it is supposed to call the default constructor. If I wanted to call a single-arg constructor, I'd say new("whatever"). Your proposed feature only works with a zero-arg constructor.