Support records on .net framework and netstandard 2.0 target

[smoothdeveloper]

I don't understand the reason why records aren't supported out of the box in .net framework or netstandard targets.

Most of the existing codebases would benefit from it, and it shouldn't be a big deal to provide support for the constructor syntax, dismissing the init based property initializer syntax.

Improvements on grounds of immutability and shorthand declaration to cut the clutter benefit the existing, larger codebases more, in quantifiable manner, it helps the language stir in the right direction more codebases in the wild.

Instead, people have to go the "artisanal route":
https://blog.ndepend.com/using-c9-record-and-init-property-in-your-net-framework-4-x-net-standard-and-net-core-projects/

Meaning more clutter, more unsupported stuff, in each projects that needs to define records.

This is not helping the C# ecosystem and developers that are restricted to targets < net 5.0 (the vast majority of C# developers).

What was the deciding factor for not shipping that for "everything but the very latest"?

Can this be addressed?

[jnm2]

Are you asking for the compiler to declare an internal static class IsExternalInit if it doesn't exist already instead of erroring if you use init, just like it does for NullableAttribute? Or do you mean 'support' in some other way? New types can't be added to any shipped version of .NET Framework/Standard, and no new versions of these are planned (and there's nothing C# can do about that happenstance).

This is not helping the C# ecosystem and developers that are restricted to targets < net 5.0 (the vast majority of C# developers).

https://www.surveymonkey.com/stories/SM-GDSVMB2C/:

While the 4,486 respondents probably self-selected in a way that didn't make them representative of all C# developers, 38% is the maximum percentage that could possibly have been restricted to targets < net5.0 and likely the percentage is even smaller (some, like me, are not restricted from targeting net5.0 and just didn't do it yet). Again, it's hard to estimate the effect that the sampling bias might have. But for me it lowers my credence for the statement "the vast majority of C# developers are restricted to targets < net5.0."

[smoothdeveloper]

@jnm2, sorry if my post wasn't clear, and thanks for prompting me to clarify.

I guess I'm asking for records that would be compiled for netframework & netstandard & netcore targets to work as they would if they were classes with constructor and readonly properties / backing fields.

Along with support for the with syntax if possible, of course.

public record MyRecord(int MyField);

if there is no init support, it would roughly desugar to

public class MyRecord {
   public MyRecord(int MyField){
    this.myField = MyField;
  }
  private readonly myField;
  public MyField => myField;

  // other generated members for cloning, hashcode & equality ommited for brievety
}

If there is support, then, you allow the init syntax, but this is really a minor edge case of using records, records could have existed without init even being a thing.

Cons of not doing the suggestion:

Not having the records for all the targets that C# compiler supports (could be down to .NET 1 technically), just because runtime doesn't have init construct, hurts C# codebases, and the developers (who will go the unsupported "artisanal" route if they feel compelled to improve what they work with, despite lack of support), this keeps the dark matter C# codebases, in the dark.

Pros of doing the suggestion:

On the opposite, by supporting this suggestion, you enable all C# codebases to have more sensible constructs to define data types, without discriminating if they are targetting latest version of runtime.

New types can't be added to any shipped version of .NET Framework/Standard, and no new versions of these are planned (and there's nothing C# can do about that happenstance).

I'm unclear, do you mean BCL types? or new type constructs that a language may, sometime, add support for?

Again, it's hard to estimate the effect that the sampling bias might have. But for me it lowers my credence for the statement "the vast majority of C# developers are restricted to targets < net5.0."

It may be OK to rebut what is just my intuition versus an actual survey, but, in my intuition, if I take 100% of existing C# codebases that 100% of C# developers maintain, the share of those codebases where one can currently declare a record to an arbitrary C# project is tiny, not 60% like the survey shows.

Does that make sense?

[jnm2]

I believe init is necessary in order to implement with. It can't be done on top of readonly from what I remember.

The simpler choice for the language is the current state of things where it's trivial to reference a package or define IsExternalInit yourself. This is especially going to be reinforced by the fact that Microsoft has made it clear that they do not intend to support C# 8+ on .NET Framework at all; if parts happen to work, then awesome. (I use C# 9 on .NET Framework/Standard and recommend it personally; pattern matching etc are still great.)

I'm unclear, do you mean BCL types? or new type constructs that a language may, sometime, add support for?

BCL types. In case what you were saying was that .NET Framework should ship the IsExternalInit type, but you've clarified that this isn't what you were saying.

It may be OK to rebut what is just my intuition versus an actual survey, but, in my intuition, if I take 100% of existing C# codebases that 100% of C# developers maintain, the share of those codebases where one can currently declare a record to an arbitrary C# project is tiny, not 60% like the survey shows.

That makes sense.

[smoothdeveloper]

A moderator can close this discussion (as I can't), I hope nothing sounded disparaging:

• I'll define the IsExternalInit in C# projects that can't target net 5
• I'm updating bits of F# type checker to honour the modreq ((experimental) forbid setter call on init properties fsharp#11564) which helped me understand there is no runtime change

Take away I'd like the C# team to consider:
Please do your best to go the extra length to bring features to all supported targets, people maintaining codebases frequently have no easy way to just transition out of .net framework, those codebases need the better C# as much as greenfield ones starting on latest runtime/sdk.

Not having the features available is not a good way for pushing people to ugprade their runtime/sdk, it just keeps C# developers away from picking up the new features for longer, and is detrimental to the idioms that ought to gain ground in more C# codebases.

I wonder what is the cutoff to not go that extra mile, but it has seemed too low, judged with my own bias.

[HaloFour]

The team has taken the position that the language will continue to evolve in lockstep with the runtime, and that new features will only be officially supported on the corresponding runtime. This is to allow the language designers to consider more language features that will depend on runtime changes. While that's not true of all (or even most) new language features, tracking which features can be polyfilled has been deemed challenging enough to not be worth the extra effort involved.

[smoothdeveloper]

@HaloFour, thanks for the clear statement on the approach.

That reminds me of "just copy System.Core.dll, as I need C# 3.0 features while targeting .NET 2.0 project" and this approach hasn't changed.

I understand better the pros and cons of the approach and how they apply to the language design and the progress on runtime features gradation.