Allow omitting type of constructor argument with the same name as field to set that field

[Thaina]

Instead of

public class SomeThing
{
    Dictionary<SomeLongNameKeyType,SomeLongNameKeyValue> dict;
    public Something(int i,Dictionary<SomeLongNameKeyType,SomeLongNameKeyValue> _dict,float f)
    {
         dict = _dict;
         // initializing
    }
}

public struct Vector3
{
    public float X,Y,Z;
    public Vector3(float x,float y,float z)
    {
         X = x;
         Y = y;
         Z = z;
    }
}

I think this pattern is very common and could be easily shorthand by compiler

public class SomeThing
{
    Dictionary<SomeLongNameKeyType,SomeLongNameKeyValue> dict;
    public Something(int i,dict,float f) // exactly same name as member
    {
         // initializing
    }
}

public struct Vector3
{
    public float X,Y,Z;
    public Vector3(X,Y,Z) { } // exactly same name as member
}

edit : As of concern by @theunrepentantgeek and some other reason. I retract the ability to allow setting property and limit to field only

[theunrepentantgeek]

At first glance, I see a conflict between this proposal and the very well established naming conventions used for C# code.

Method (and constructor) parameters are camelCase.
Properties are PascalCase.

Admittedly, member fields are often camelCase, but lots of people use coding standards with _one prefix or m_another ... and exposing public fields is almost inevitably an invitation for future maintenance costs.

[canton7]

Take a look at the Records proposal and the Primary Constructors proposal.

[Thaina]

@canton7 Already seen those but I think they are all overkill when we just sometime want some member to be easily set in constructor. With my proposal it don't need anything but a little compiler magic this.member = member

[canton7]

It's probably worth making clear in your proposal why yours is superior to those other two proposals. Records already has a proposal champion in the form of the C# Language PM, and Mads has also written a proposal for primary constructors.

Your proposal will need some very, very strong points in its favour to garner more support than those two, and you will need to make those points very clear.

[Thaina]

@canton7 As I said I think both of those is overkill to make a completely whole new syntax and too much restraint for the use case. And it actually not related to my proposal that work on the constructor itself. Not a class

It could also use in multiple constructor and could be utilized in all existing codebase that fall into this pattern

It also not go against the record or primary constructor too so I don't think it should be concerned about those 2 proposal

The primary constructor itself are more likely clashing with records. Why you need to concern about this feature?