Properties with optional {get;set/init;}? / Compile public fields as auto properties

[bugproof]

Pretty much every other language allows defining properties in a simple syntax like:

F# records:

type Person = {Name: String; Age: int}

Rust:

struct Person {
    name: String,
    age: u8
}

Typescript:

type Person = {
  name: string;
  age: number;
};

Kotin makes properties first-class https://discuss.kotlinlang.org/t/property-vs-field/8179
In Kotlin backing field cannot be defined directly... you need to use someProperty.field

I think it would be great if there was some solution in C# to make defining properties like {get;set;} or {get;init;} in some easier way. Either some .csproj switch that will automatically convert fields to props or some other way.

We will be getting primary constructors #2691 and field keyword.

I think it would be great if we could define properties without explicitly adding get/set/init

e.g. for records it would automatically default to {get;init;}.. unless explicitly set

public record Person {
  string Name;
  int Age;
}

[bernd5]

If you don't use custom getters / setters - what is wrong with normal fields?
If you need to change those you can convert them to properties later without breaking source code - properties and fields are source compatible - just not IL/Binary compatible.
Is this your real problem?

[bugproof]

The problem is many libraries respect only properties and not fields. And yes, most of the time I don't need custom getters/setters + certain attributes work only on properties([AttributeUsage(AttributeTargets.Property)]). I really like how kotlin solved it https://discuss.kotlinlang.org/t/property-vs-field/8179 it's always property and you can optionally define custom getter/setter. If this was possible you could e.g. define <ImplicitProperties>true</ImplicitProperties> in .csproj and completely remove {get;set;} and {get;init;} from your code and access fields only with field or PropertyName.field #140

Also it's a bad practice to use public fields: https://softwareengineering.stackexchange.com/questions/161303/is-it-bad-practice-to-use-public-fields

[webczat]

It's a bad practice to use public fields but there are cases where they are used explicitly, even in the dotnet bcl. for example some attributes have public fields not properties. High perf scenarios may demand making a struct with just fields... etc. Correct me if I am wrong.

[Joe4evr]

High perf scenarios may demand making a struct with just fields... etc. Correct me if I am wrong.

These days, the JIT can (apparently) produce much better code for simple-/auto-property accesses than it does for fields.

[webczat]

interesting, how so? still not sure how that works with things like explicit layout control or sequential layout/C interop, if you have a struct full of auto implemented props, are their backing field laid out correctly?

[Joe4evr]

I don't really know why (I simply saw a post by a runtime dev (jkotas) recently saying so without explanation), but if you're after explicit layout, you can use the field specifier on properties to make that happen.

[canton7]

public record Person(
    string Name,
    int Age
);

That's close enough? That gives you properties which are { get; init; }. Although, it doesn't give you a parameterless constructor, it's true.

[bugproof]

Yes this forces you to use the constructor. Maybe when required keyword will be available to use then compiler could generate parameterless constructor as well? 🤔

[Clockwork-Muse]

At least for Rust (and FSharp) these aren't properties, they're still fields, and so are equivalent to just the bare struct definition in C# (no get/set equivalent).

I actually consider this a problem - at least some of what I want to do in Rust would have been nicer if I could use a different backing field than what is exposed.

[bugproof]

@Clockwork-Muse actually when you take a look at how F# code is compiled they're properties. https://fsharpforfunandprofit.com/posts/fsharp-decompiled/#records

For Rust you are right. It's just about how nicer type definitions look in all the other languages compared to C#. Kotlin already has it and primary constructors too

[Clockwork-Muse]

Maybe so, but there's no way to declare a backing field, so the effect is the same.

[HaloFour]

Properties will always need a different syntax from fields given the team has expressed a desire to avoid dialects, so they will always be in some way more verbose.

I'm of the opinion that the current auto-property syntax is not at all burdensome. It's only a couple of additional keystrokes if you type them by hand, and most IDEs will have a template/snippet which will "type" that for you.

Those other languages chose to not have fields (or only have one syntax, whether they are fields or blur the lines between fields and properties). C# has both and will always have both.

[bugproof]

Yeah it's not a problem. It's only code clarity + C# already has opt-in features like nullable reference types. I don't see where your pessimism comes from...?

[svick]

public record Person {
  string Name;
  int Age;
}

This is already valid syntax, and changing what that code means would be an unacceptable breaking change. So you would need to invent some new, more complicated syntax for this.

[bugproof]

Sure, but we already have opt-in features of C# language like half-baked nullable references so I don't see a problem with another .csproj option like <ImplicitProperties> that changes how your code compiles. Or if it was possible to write compiler extensions... dotnet/roslyn#637

[spydacarnage]

I see there being a difference between simply enabling a compiler option (like NRT, or Unsafe) and changing what code means.

If I see string? Name or unsafe in code, I know what this means, whether the compiler option is turned on our not.

In your example, the code means one thing, unless I check the csoroj file and it tells me it means something else. That's the difference, and why I don't think this is going to fly.

[HaloFour]

Sure, but we already have opt-in features of C# language like half-baked nullable references so I don't see a problem with another .csproj option

Having one such option isn't opening the door for more. The team has been very upfront about not wanting to add dialects unless the benefit is absolutely massive. Null references have been called the "billion dollar mistake", so it's one of the few (if not the only) types of problems to be deemed worthy of a dialect. And even then NRTs don't change the semantics of the code; it still behaves exactly the same way regardless of whether the option is enabled. You might think that's half-baked, but that was very intentional given the massive impact type changes would have on the ecosystem and 20 years worth of existing code.

[theunrepentantgeek]

I don't see a problem with another .csproj option

Keep in mind @bugproof that each additional option flag doubles the number of dialects of the language. Flags don't add, they combine - and the combinatorial explosion is deadly, because the interactions of every combination of flags needs to be evaluated, documented and tested.

With all the plaintive "just add a flag" requests we've seen here over the last couple of years, we'd literally have a billion (yes with a B) or more dialects of C#. Nothing would drive developers away from the platform faster than that.