Parameter properties

[gafter]

@zpul commented on Fri Jun 10 2016

Any chance to have parameter properties in C# 7 as in Typescript?

Reference:
https://www.typescriptlang.org/docs/handbook/classes.html#parameter-properties

---

@zpul commented on Fri Jun 10 2016

This example usage of Typescript better makes the point:
https://www.stevefenton.co.uk/2013/04/stop-manually-assigning-typescript-constructor-parameters/

In C# the same example

public class Person {
    public string firstName { get; set; }
    private string lastName { get; set; } = "n.a.";

    public Person (string firstName, string lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

shortens to this:

public class Person {  
    public Person (public string firstName, private string lastName = "n.a.") { }
}

---

@HaloFour commented on Fri Jun 10 2016

That sort of shorthand is proposed for record types: #10154

public class Person(string firstName, string lastName = "n/a");

The one thing that I don't think has currently been resolved in that proposed spec is allowing for explicit member access modifiers on the parameters of the primary constructor.

---

@zpul commented on Fri Jun 10 2016

@HaloFour thanks for the pointer!

In my understanding record types are very useful but only when creating storage-only classes.

The parameter properties described above are more general I think:

• they apply to classes in general and target any access modifier (public/private/etc.)
• AFAIK they help/shorten a very frequent coding pattern

I would like having both, however if I have to choose one of them, I would prefer definitely parameter properties for their large applicability.

---

@MgSam commented on Fri Jun 10 2016

I never much cared for TypeScript's implementation of this feature because it makes it harder to see at a glance what the properties of your class are.

I think that problem would be compounded even further in C#, because in C# you can have multiple constructors (in TypeScript/JavaScript, you can only have a single constructor). It would be weird to have properties declared in one constructor that might be somewhere else in the code from the constructor you're looking currently.

---

@HaloFour commented on Fri Jun 10 2016

@zpul

Perhaps. Records can contain class bodies complete with other methods, properties, etc. But they are proposed to automatically generate other record-specific boilerplate such as a deconstructor and possibly "withers". The syntax and functionality of your proposal is very similar so maybe the two could be considered side-by-side, whereas "property parameters" can be declared in normal constructors, but are promoted to "primary constructors" when the parameter list is moved to the type declaration:

public class Person {
    public Person(public string firstName, private string lastName = "n/a") { }
}

public class PersonRecord(public string firstName, private string lastName = "n/a");

Something that your proposal might have to take into consideration is that the C# naming guidelines stipulate that property names are PascalCase while parameter names are camelCase. The record proposal solves this through having a second identifier declared on the primary parameter, e.g.:

public class Person(string firstName FirstName, string lastName LastName);
...
var person = new Person(firstName: "John", lastName: "Smith");
Console.WriteLine($"Hello Mr. {person.LastName}!");

@MgSam

You're right, as with primary constructors it could only work if the type only had a single constructor. I also agree that it would be too easy to lose track of those members, and it's weird for something declared within the parameter list of a member to have a scope beyond that member.

---

@zpul commented on Fri Jun 10 2016

@MgSam Very interesting point, however I think that it can be addressed in some way.
I agree with @HaloFour that it has to be limited in some way, either this should work on classes with one constructor or it should work only on one of them.
To address your comment the languange syntax can state that this constructor should be the first one and should appear at the very beginning of the class.

@HaloFour Thanks for the valuable feedback.
About CamelCasing I am usually not very strict on it however any idea such the one on record types is fine for me.

---

@alrz commented on Mon Jun 13 2016

Not as the primary syntax for records, but I think this would be useful as an alternative.

Related: dotnet/roslyn#10154 (comment)

---

@aluanhaddad commented on Thu Jun 30 2016

Whenever I use TypeScript and need to create a class I use this notation for brevity but it's actually a little weird.
public and protected make sense but private is really an odd ball because it exposes an implementation detail as part of a type's interface to simplify its implementation. The counter argument is that you should follow the principle of least privilege which which suggests the use of private. However, in that case it would be better to not declare the fact that the value is being captured into a property at all, and just do the wiring manually.

[jnm2]

@aluanhaddad

public and protected make sense but private is really an odd ball because it exposes an implementation detail as part of a type's interface to simplify its implementation. The counter argument is that you should follow the principle of least privilege which which suggests the use of private. However, in that case it would be better to not declare the fact that the value is being captured into a property at all, and just do the wiring manually.

I don't think the fact that the parameters are captured into fields becomes part of the public metadata no matter what the visibility is. All we're talking about is implementation syntax, not touching the signature or API contract.

[binki]

Distinguishing Fields and Properties

In TypeScript where this discussion started, there is no distinction between fields and properties. Everything in JavaScript is a property. So the mere presence of public, protected, or private in the constructor’s parameter list is sufficient to signal to the reader that the parameter should be a property in TypeScript.

However, in C#/.net, we have both fields and properties. Thus, the mere presence of public or private keyword in the constructor’s parameter list is insufficient to signal to the reader that the result is a property. I think that @aluanhaddad indirectly raises a good point when saying that private is odd here: private is optional in the normal declaration of a property. I’d thus expect to be able to omit private from my parameter property declaration.

I think either a new keyword such as property or including the { get; } in the parameter list is necessary to clarify that the parameters will become properties.

[adam-pooler]

I'd love to have to type less constructor assignment code. I can see the problems with the TypeScript syntax in c#, but how about something like this?

    class TestBaseClass
    {
        private int _a;

        public TestBaseClass()
        {
        }

        public TestBaseClass(set _a)
        {
        }
    }

    class TestClass : TestBaseClass
    {
        private string _s;

        public string T { get; set; }

        public TestClass(set _s, set T)
            : base()
        {
        }

        public TestClass(int a)
            : base(a)
        {
        }
    }

In this case, the compiler could auto-generate default names for the constructor parameters and it's clear what fields/properties are set.