Cannot enfore generic method to accept record

[Rainmaker52]

Description

When creating a generic method on .NET 5, it is not possible to enforce the generic to be a "record" type. Instead "where T: class" needs to be used.

In my opinion, this should be possible. It will also hint to the compiler the input is read-only.

Example

// Compiles. And, oddly enough, allows /records/ to be passed in:
public async ValueTask SendMessage(T message) where T: class
// Does not work:
public async ValueTask SendMessage(T message) where T: record

For the bot: Label area-TypeSystem-coreclr possibly?

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[svick]

See the recent discussion following #39 (comment), where the conclusion was that this would not be useful, for example:

The intent with records is that, hopefully in C# 10, there won't be a meaningful semantic difference between a record and a class. You'll be able to get all the benefits of records (such as withability) in either the full form of a class or in the smaller record declaration. I'm just not sure what you actually want to to constrain to with that.

Keep in mind that records don't have to be read-only. For example, the following is a perfectly valid record:

record R
{
    public int I { get; set; }
}

[CyrusNajmabadi]

It will also hint to the compiler the input is read-only.

Records are not read only :-)

[333fred]

As stated in the conversation svick linked, this is very much by design. We'll let this issue stay open as a separate place to discuss this further, but please do read the conversation at that link as it contains a lot of info as to the motivations of the design team here.

[Bomret]

But there is a very important distinction between a class an a record. For a record I can use a with expression, for a class I can't. I currently would like to write a method that goes something like this:

interface IBook {
  string Author { get; }
  string? DisplayName { get; }
  string? Description { get; }
}

record SimpleBook : IBook {
  public required string Author { get; init; }
  public required string ISBN { get; init; }
  public required string Content { get; init; }
  public string? DisplayName { get; init; }
  public string? Description { get; init; }
}

T Read<T>(string filePath) where T : IBook, record {
  T content = // deserializing the file from json
  var translation = ReadTranslationFor(filePath);
  
  return content with {
    DisplayName = translation.DisplayName,
    Description = translation.Description
  };
}

var myBook = Read<SimpleBook>("~/Documents/Books/my-book.json");

Currently this doesn't work because for the compiler, classes and records are not semantically the same.

[HaloFour]

I think ehe better answer there would be to support "with" across more types via a pattern, one that can be described as an interface or constraint: #162

[333fred]

Yes. We considered this exact type of scenario during the design of records, and the preferred solution is the ability to make something withable, not specify that it is a record.

[MinzigesTV]

Yes. We considered this exact type of scenario during the design of records, and the preferred solution is the ability to make something withable, not specify that it is a record.

Is there anything planned for the future? Would be a nice feature.

[mattwar]

The class constraint does not constrain to classes. It is just a reuse of an existing keyword and means constrain to any reference type. Likewise the structure constraint means constrain to value types.