Withable interfaces - abstraction support for records

[bernd5]

Motivation

I very much like the record feature especially with init-only properties to create immutable data structures.

There is just one very big problem in my eyes - which is that there is no way to abstract away from concrete record-type implementations.

The problem is that we can't use with for records/structs behind interfaces.

E.g. we can't write:

using System;

IFoo foo = new Foo() { Pos = 1, Text = "Bar" };

var newFoo = foo with { //--> error CS8858: The receiver type 'IFoo' is not a valid record type and is not a struct type.
    Text = "Foo"  
};

record Foo : IFoo
{
    public int Pos { get; init; }
    public string Text { get; init; }
}

interface IFoo
{
    int Pos { get; init; }
    string Text { get; init; }
}

Possible solution

Therefore I propose a "wellknown interface" which allows using with for interface types - (here I took the name System.IRecordLike).

So the following code would become legal:

using System;

IFoo foo = new Foo() { Pos = 1, Text = "Bar" };

var newFoo = foo with {
    Text = "Foo"  
};

record Foo : IFoo
{
    public int Pos { get; init; }
    public string Text { get; init; }
}

interface IFoo : IRecordLike // <-- well known interface to mark the interface as withable
{
    int Pos { get; init; }
    string Text { get; init; }
}

The interface IRecordLike should be implicity supported for records and structs but not for classes.

It could look like:

public interface IRecordLike
{
    object Clone();
}

ABI compatibility

It would be great if we would not need to recompile existing records and structs to support this feature - so IRecordLike should not needed to be explicitly implemented by structs or records to support withing (on IL-Level).

For "withing" with IRecordLike-interfaces the compiler could call a special method like System.Runtime.CompilerServices.RuntimeHelpers.CloneInterfaceInstance which could look like:

public static object CloneInterfaceInstance(object o) //we can't use IRecordLike as a parameter type to allow a "by convention implementation"
{
    //explicit interface implementation
    if (o is System.IRecordLike recordLike){
        return recordLike.Clone();
    }
    
    //structs
    if (o is ValueType){
        return System.Runtime.CompilerServices.RuntimeHelpers.GetObjectValue(o);
    }
    
    //records (can we optimize this?)
    var t = o.GetType();
    var m = t.GetMethod("<Clone>$", Array.Empty<Type>());
    if (m is not null){
        var copy = m.Invoke(o, Array.Empty<object>());
        return copy;
    }
    
    throw new NotSupportedException();
}

To allow this the compiler should not issue an error for the "missing" IRecordLike.Clone() method - it should treat as implicitly supported.

Alternative definition for IRecordLike

Another option would be to define IRecordLike as an empty interface type - but the compiler should not allow it to be implemented by classes explicitly.
In the future we could introduce maybe a IRecordLikeClass with the specified Clone method.

Alternative to IRecordLike

Another option would be to mark the interface as withable via attribute.

[HaloFour]

If "withers" become based on a pattern vs. the current "unspeakable" API I think it would automatically become extended to interfaces by virtue of that interface exposing that pattern.

[bernd5]

Is there a proposal for pattern-based with? I asked for Clone() and/or ICloneable.Clone() but the problem is that the implementation of those methods are often quite bad / have custom semantics.

From the docs

we recommend that ICloneable not be implemented in public API

---

Another option would be to extend the init scope - that would help for factory methods, too.
E.g.

var someRecordLikeObject = Factory.CreateSomething();
init(someRecordLikeObject) // "init statement" - allows init-only setter access
{
    someRecordLikeObject.InitOnlyProperty = "Foo";
}

[HaloFour]

Here's the championed issue for it: #162

And the non-championed issue for extending initializer syntax to factory methods: #803

Doesn't seem like either conversation has moved in a while.

[bernd5]

Thanks

[bernd5]

Btw.: is there any way to make use of init-only properties defined in interfaces (currently they seem to be useless for me)?
The only locations where those properties can be assigned (AFAIK) are constructors, object initializers and withers. Do I miss something?

[CyrusNajmabadi]

it coudl be a type-parameter constrained with an interface and with new() i believe.