Generic type constraint for records (or more general an immutable type)

[MCGPPeters]

Consider this example of a delegate:

    public delegate void F<T>(T state);

In my example I want to make sure that implementers are not able to alter the state, so I want to enforce T to be an immutable type.

    public delegate void F<T>(T state) where T : record

Adding the constraint would be a solution. Would be great if an option like this would be available in the language.

Thanks for your time

[Joe4evr]

Duplicate of #3859 / #39 (comment).

In short, there is intentionally no way to distinguish between a record and a regular class, and there is no desire to change that.

[HaloFour]

so I want to enforce T to be an immutable type.

There's also the issue of records not being immutable, despite how much the documentation claims that they are.

[CyrusNajmabadi]

so I want to enforce T to be an immutable type.

C# has no such concept. Note: records are not immutable. Evenif we could add a record constraint there would be nothing about that would ensure "that implementers are not able to alter the state"

[MCGPPeters]

Consider me misled ... By myself .😁 ... Tnx for the explanation...

[DriDrood]

I have this situation:

var a = new record();
var b = a with { };

This is totaly fine. But when variable a is class, it will rise error CS8858: The receiver type 'TEntity' is not a valid record type and is not a struct type. So there is way to distinguish between a record and a regular class, isn't it? I want to use this with feature with generics and now it is impossible.

[HaloFour]

See: #3859 (reply in thread)

[SGStino]

This doesn't make much sense, does it?

public record RecordBase();

public £T DoSomething<T>(T input) where T: RecordBase
{
   return input with {}
}

However, this makes a lot more sense, and is actually possible already:

public record RecordBase(string Value);

public £T DoSomething<T>(T input, string newValue) where T: RecordBase
{
   return input with { Value = newValue}
}

What would be more sense instead of the first case would be if a record would implement IClonable

public T DoSomething<T>(T input) where T: IClonable
{
   return (T)input.Clone()
}

But: CS8859: Members named 'Clone' are disallowed in records.

For #3859 (reply in thread), there's a bit of an issue with the interface only declaring getters, so nothing guarantees that the record needs to implement setters for those properties.