record and record? generic constraints

[RenderMichael]

A couple of times I've written generic methods and wanted access to the with keyword, in order to copy T so as not to mutate the original.

As a workaround I had to reflect into object.MemberwiseClone(), which was enough for my use case but it's not an optimal solution.

usage:

public static T RemoveId<T>(T obj) where T : record, IHasId
{
    return obj with { Id = null };
}

There's been discussion of expanding the with keyword beyond records, but this is a much less invasive and much less opinionated feature.

[HaloFour]

Without redesigning how with works this wouldn't be possible to manage via generic constraints because there is no common method used to clone the record. Each record defines its own independently.

[RenderMichael]

much like the new() constraint uses Activator.CreateInstance() under the hood, maybe this can just reflect into the <Clone>$ method

[HaloFour]

That's an implementation detail that may change in the future.

[RenderMichael]

records defined against one SDK does not need to work on a different SDK right? Since it doesn't use a source-generator or anything.

So if <Clone>$ is an implementation detail that changes, the record generic parameter implementation can change as well. Though I can see how this may limit the wiggle room available.

Especially given the UnsafeAccessorAttribute shipped in .NET 8, reflection of a well-known member can be performant.

[HaloFour]

Also, see: #3859

IMO, the teams effort would be better spent describing "withers" as a pattern that can be supported by generic type constraints, rather than adding one specific generic type constraint specific to the current implementation of records.

[RenderMichael]

That's fair enough. It would be nice if the "wither" pattern could fit a generic constraint as well

[TonyValenti]

I have an empty base class called DisplayRecord that all my records inherit from. I can then use constraints and get WITH.