C#•3y ago

❔ Default implementation of a `static abstract` base interface member in derived interface

I am trying to implement an idea I saw in MessagePack for C#:

public interface IMemoryPackable<T>
{
    static abstract void Serialize<TBufferWriter>(ref MemoryPackWriter<TBufferWriter> writer, scoped ref T? value)
        where TBufferWriter : IBufferWriter<byte>;
    static abstract void Deserialize(ref MemoryPackReader reader, scoped ref T? value);
}

public interface IMemoryPackable<T>
{
    static abstract void Serialize<TBufferWriter>(ref MemoryPackWriter<TBufferWriter> writer, scoped ref T? value)
        where TBufferWriter : IBufferWriter<byte>;
    static abstract void Deserialize(ref MemoryPackReader reader, scoped ref T? value);
}

where using

static abstract

static abstract

surfaces the methods on the type itself, which I find very useful.

I came up with this:

public interface IDispatchable<T>
{
    public static abstract bool Initialize();
    public static abstract bool Serialize(in ROS<T> src, in Span<byte> dest, out int bytesWritten);
    public static abstract bool Deserialize(in ROS<byte> src, in Span<T> dest, int srcLen);
}

public interface IDispatchable<T>
{
    public static abstract bool Initialize();
    public static abstract bool Serialize(in ROS<T> src, in Span<byte> dest, out int bytesWritten);
    public static abstract bool Deserialize(in ROS<byte> src, in Span<T> dest, int srcLen);
}

Now- if

were a struct, I can provide good default impls, so I declare a derived interface that constrains

public interface IBlockDispatchable<T> : IDispatchable<T> where T : struct { }

public interface IBlockDispatchable<T> : IDispatchable<T> where T : struct { }

Can this interface now declare a default implementation of the static abstract members of

IDispatchable<T>

IDispatchable<T>

such that implementing structs surface that default implementation?

I know the derived interface can declare an explicit impl of the base interface method, but then the explicit impl is not available through the struct's type as I expect

static abstract/virtual

static abstract/virtual

members to be.

If this is not the correct way to approach this, I'm open to all suggestions on how I can provide specialized behavior to structs in this particular instance. Thank you!

peppyOP•4/20/23, 10:05 AM

Could an idea here be to declare extension methods for

IDispatchable<T>

IDispatchable<T>

with struct constraints and give the implementations there instead of a derived interface?

peppyOP•4/20/23, 10:51 AM

To further elaborate, the usecase is:

and I have tested this and it works perfectly fine when some struct/class implements

IDispatchable<T>

IDispatchable<T>

fully itself.

The key point is that sometimes- for instance, structs where you don't want any custom behavior like ignoring fields; a correct (and more optimal) default impl can be provided with ease, and I see no reason to require types like that to write it out by hand.

peppyOP•4/20/23, 11:03 AM

But if I do:

or however you're supposed to syntactically achieve this, my expectation is that for some struct:

should be available, use that default impl, and not require the struct to write it out.

peppyOP•4/20/23, 12:06 PM

Mind you that it would be entirely valid for me to eliminate and simply write out the same exact implementation of in every struct, but surely there is a way to avoid having to write it out a hundred times over?

peppyOP•4/20/23, 12:33 PM

The above example of is trying to implement or at least override a

static abstract

static abstract

base interface method, but I also have a usecase where the idea is to reabstract said base interface.

Let's say that the user should provide custom (de)serialization calls at the class/struct level. I do not need them to implement as is, with a signature used for batches of data; it's enough to know how one item should be serialized and the method for a batch is trivially constructible. A reabstraction comes to mind like this:

but again, this way the default would not be available as for some or the aforementioned if it chose to implement this for the sake of, say, ignoring a field or writing in extra data.

Accord•4/21/23, 12:38 PM

Looks like nothing has happened here. I will mark this as stale and this post will be archived until there is new activity.

peppyOP•4/26/23, 11:10 PM

In case anyone does somehow stumble upon this like a year later, the answer is https://github.com/dotnet/runtime/issues/79603.

The code above is valid, but methods must be marked instead of

static abstract

static abstract

with a default impl. Not great, but doable. The explicit interface implementation can be accessed with generic indirection.