FYI Amusing C# [Properties, Collection initialization, LINQ, etc.]

[DracoConstellation]

Hi everyone.
To avoid long stories I'll get straight to the point... Being a programmer, I check third-party open-source projects. Over the time I have collected a number of interesting C# features that I would like to share with you.

Properties and how they can be used
As we all know, a property is a pair of functions - accessor and mutator - designed for writing or reading the value of a field. At least, things used to be that way before the release of C# version 3.0. In it's
traditional form, a property used to look like this:

class A
{
  int index;
  public int Index
  {
    get { return index; }
    set { index = value; }
  }
}

Years went by, and both the language standards and properties have acquired a number of new mechanisms.
So, here we go. The C# 3.0 standard brought us the well-known feature that allowed you to omit the field; that is, to declare a property in the following way:

class A
{
  public int Index { get; set; }
}

The idea was pushed even further in C# 6.0 by allowing programmers to omit "set" as well:

class A
{
  public int Index { get; }
}

It was possible to use this style before C# 6.0 too, but you could not assign anything to a variable declared in such a way. Now it has in fact become an equivalent to readonly fields, i.e. the values of such properties can be assigned only in the constructor.
Properties and fields can be initialized in different ways. For example, like this:

class A
{
  public List<int> Numbers { get; } = new List<int>(); 
}

Or like this:

class A
{
  public List<int> Numbers = new List<int>();
}

One more version:

class A
{
  public List<int> Numbers => new List<int>();
}

In the last case, though, you will be unpleasantly surprised. You see, what we have actually created there is the following property:

class A
{
  public List<int> Numbers { get { return new List<int>(); } }
}

That is, an attempt to fill Numbers with values will inevitably fail; you'll be getting a new list every time.

A a = new A();
a.Numbers.Add(10);
a.Numbers.Add(20);
a.Numbers.Add(30);

So be careful when using shorthand notations, as it may result in long bug-hunting sometimes.
These are not all the interesting features of properties. As I have already said, a property is a pair of functions, and in C# nothing prevents you from changing the parameters of functions.
For example, the following code compiles successfully and even executes:

class A
{
  int index;
  public int Index
  {
    get { return index; }
    set { 
      value = 20; 
      index = value; }
  }
}
static void Main(string[] args)
{
  A a = new A();
  a.Index = 10;
  Console.WriteLine(a.Index);
}

However, the program will always output the number "20", but never "10".
You may wonder why one would need to assign the value 20 to value? Well, it appears to make sense. To explain this point, however, we'll have to set our discussion of properties aside for a while and talk about the @ prefix. This prefix allows you to declare variables that resemble keywords in spelling, for example @this, @operator and so on. At the same time, you are not prohibited from inserting this character wherever you please, for example:

class A
{
  public int index;
  public void CopyIndex(A @this)
  {
    this.@index = @this.index;
  }
}
static void Main(string[] args)
{
  A a = new A();
  @a.@index = 10;
  a.@CopyIndex(new A() { @index = 20 });
  Console.WriteLine(a.index);
}

The output, as everywhere in this article, is the number "20", but never "10".
The @ prefix is actually required in one place only: when writing parameter name @this in the CopyIndex function. When used elsewhere, it's just redundant code, which also lacks clarity.
Now that we know all that, let's get back to properties and take a look at the following class:

class A
{
  int value;
  public int Value
  {
    get { return @value; }
    set { @value = value; }
  }
  public A()
  {
    value = 5;
  }
}

You may think that the value field of class A will change in the Value property, but it won't, and the following code will output 5, not 10.

static void Main(string[] args)
{
  A a = new A();
  a.Value = 10;
  Console.WriteLine(a.Value);
}

This behavior is the result of the mismatch of @value in get and @value in set. In get, @value will be nothing more but a field of an A class. At the same time, in set, the @value is a parameter of the set function. Thus we just write value in itself and do not touch value filed in the A class.

More information this :nevreness: