Type proxies/transformers/decorators/generators

[IS4Code]

This is not a fully fleshed-out proposal, rather a discussion about how to best address a certain area of issues regarding automation of type transformations.

I shall start with a motivation example of remoting. One of what I view as a part of its issues was the lack of greater control over the course of operations. Invoking a method on a remotable object could mean sending a request and waiting for response from a distant server, which could be seconds apart. Yet in many cases that is not really needed to be provided as inseparable sequential operations – rather it makes sense to send a couple of requests at once and wait for the response to all of them. Thus greater control is needed.

Imagine a some sort of server with objects like this (defined in a public assembly, let's say for server plugins):

public interface IPlayer
{
    string Name { get; set; }
    int Color { get; set; }
    int Ping { get; }
    void Kick();
}

Now for some sort of remote connection utility, a mirror of this interface can be used (there are other options, but this one is the easiest to use):

public interface IAsyncPlayer
{
    string Name { async get; async set; }
    int Color { async get; async set; }
    int Ping { async get; }
    async Task Kick();
}

(Let's pretend for a moment that async properties exist, but this doesn't depend on their existence anyway.) The implementation of IAsyncPlayer can be coupled with IPlayer at runtime to create a possible implementation, and all works well, but there are obvious issues: IAsyncPlayer is fixed; changing IPlayer requires chain changes, which could be a nuisance (although should be fixable with a source generator). Still such a type exists as a new type technically, so if multiple libraries intend to use the same IAsyncPlayer, they must reference a shared assembly (which in turn must be updated when IPlayer is changed, so we are again at the beginning).

It would be really nice to have some sort of generic way of saying "it's like this type, but with these changes" where the original type and the changes themselves can be decoupled (or, more abstractly: "produce a type from these types"). That is, there should be a "type template" Async<T> that transforms Async<IPlayer> to IAsyncPlayer. Moreover, if this template is defined in a common place, Async<IPlayer> should mean exactly the same thing in any assembly that uses it (this demands some runtime support probably).

It is non-trivial to design what this Async<T> should be, and probably even harder to find a syntax for it (it seems inevitable that it ends in something similar to a source generator anyway). But the point is that the resulting type should be interoperable with uses of such a type in other assemblies. Whether it would mean for every assembly to generate its own copy of the type and merging them all at runtime, or just somehow referencing them from code, that's up to the implementation.

I can already imagine other such transformer types:

• Interface<T>. Simply takes the public non-static API of a type and forms an interface from it. While you cannot use DispatchProxy<Stream>, at least you can now use DispatchProxy<Interface<Stream>> if you promise to use Interface<Stream> from now on. There should also be Wrapped<T> struct that takes an instance of T and implements Interface<T> via the instance (or maybe the runtime will autoimplement Interface<T> for every T itself). Something to do with shapes seems also possible here. Interface<T> should also derive from actual interfaces of T, and Wrapped<T> should implement them.
• StaticInterface<T>. Like before, but take static members instead. Use StaticInterface<Console> to control consoles of newly spawned .NET processes. It seems reasonable that StaticClass<Console>/StaticWrapped<Console> should be a singleton implementing StaticInterface<Console> then.
• ConfigureAwaitFalse<T>. Exactly like Wrapped<T>, but all calls are followed by ConfigureAwait(false) wherever possible.
• Boxed<T>. A class implementing Interface<T> of a value type T. Not needed if value types start implementing Interface<T> of them, in which case there would already be an existing boxed representation of every value type.
• Memory<T>. Something more abstract that logs all operations performed on it and can perform them on other instances of T when triggered.
• Snapshot<T>. Similar to Memory<T>, but only reflects the properties of T as a record type consisting of those properties. Snapshot<IPlayer> could store Name, Color, and Ping consistently from one point of time.
• Synchronized<T>. Like Wrapped<T>, but every method call locks the instance of T. Attributes could be used to control this.

One last example – consider you have created a drawing method that uses the GDI+ Graphics class:

public void DrawSomethingComplex(Graphics gr)

This uses the Graphics class quite heavily to draw some very nice and complex things, but you realize that in the future, someone might want to use it with something else (that uses SVG for example). Let's say the use of Graphics in the method really warrants you saying "I need something that promises to behave just like Graphics". If you are on .NET Framework, you don't actually have to do anything, since Graphics implements MarshalByRefObject and thus you can use a RealProxy if you want to use your own class. But if you are on .NET Core (until proxying gets implemented again), you can now use:

public void DrawSomethingComplex<TGraphics>(TGraphics gr) where TGraphics : Interface<Graphics>

Now using it with a normal Graphics instance is easy – just use Wrapped<Graphics> and you have got a type that implements Interface<Graphics>, passes all operations to the original Graphics instance, and thanks to generics and inlining has no additional costs. All this additional versatility from a change to just one line of code. And this is still not duck-typing, since any new type used here must still implement Interface<Graphics> and thus promise: "Yeah, I really work like Graphics."

To reiterate the differences between this and source generators:

• Source generators can only outfit a pre-created type with dynamically created members. This requires creating completely new types.
• The new types do not have a unique name, instead they are created as a result of perhaps invoking a specific generator with some parameters, producing a type as a result of the expression.
• The new types also do not have a unique identity per assembly. Async<Array> used in assembly A must be identical to Async<Array> used in assembly B. This must hold both at compile time and at runtime.
• The source of truth for a new type created from T must depend solely on the current definition of T. If it is implemented with a type in the same assembly, other assemblies cannot simply use that one instead of creating their own, since the definition of T could have changed.
• The common ones listed above should be somehow rooted in the base library or compiling tools so that everyone can use them without additional dependencies.

---

As for the actual implementation of this, I can think of something along the lines of this:

• Type generator is a class that either creates C# code, or dynamic CIL modules. It can have type parameters.
• It must provide the means to identify the result of the construction (name of the type in case of C# code, TypeBuilder in case of CIL).
• It is invoked both by the compiler and the runtime. The compiler needs it to create a snapshot of the resulting type, for validating code that uses it. The result becomes a part of the whole compiled assembly, both for verification purposes, and for runtimes that do not support the next feature. The generated type (and all other non-nested types created at this stage) are given unique names and marked internal.
• The runtime must support "shared types". The generated types must be marked with an attribute that a compliant runtime should recognize, telling it to invoke the generator once more and create the final runtime representation of the type (in case the snapshot is already outdated).
• The snapshots are unified with the newly constructed type. If there are differences between members, it is treated as referencing an incompatible type.
• If the runtime doesn't understand the attribute, all code simply uses the assembly's own copy of the resulting type. Everything will still work, except for interchangability.

[HaloFour]

A lot of this feels like shapes, except for maybe this auto-creation of alternate versions of APIs. There's a lot to unpack there, but IMO trying to auto-generate an async or cross-process version of IPlayer is not something that should be automated because it would almost invariably wrong, like IAsyncPlayer is.

[IS4Code]

Well the auto-creation of alternate versions of types is the core and perhaps only part of the idea. Matching Interface<Graphics> does in a sense go close to shapes, but without the need to redeclare anything. Creating an automatic shape from a type's both non-static and static API is another possible feature on the list.

Maybe Async<T> was not the best initial example, but it mimicks what a remoting-like service would do to every object. How is it wrong though?

[IS4Code]

An example of what the transformations should look like:

interface I
{
    void A();
}

struct S : I
{
    public int F;
    public int P { get; set; }

    public void A() {}
    public void B() {}

    public static void C() {}
}

/* Auto-generated */
// S in these examples means specializing for the concrete struct S above

interface Interface<S> : I
{
    ref int F { get; }
    int P { get; set; }
    void B();
}

struct Wrapped<S> : Interface<S>
{
    public S Value;

    public ref int F => ref Value.F;
    public int P { get => Value.P; set => Value.P = value; }
    public void A() => Value.A();
    public void B() => Value.B();
}

interface StaticInterface<S>
{
    void C();
}

struct StaticWrapped<S> : StaticInterface<S>
{
    public void C() => S.C();
}

class Boxed<S> : Interface<S>
{
    private S value;
    public S Value => value; // value can modified only by its methods, not overwritten by another value

    public ref int F => ref value.F;
    public int P { get => value.P; set => value.P = value; }
    public void A() => value.A();
    public void B() => value.B();
}

record Snapshot<S>
{
    public int F { get; init; }
    public int P { get; init; }
}

The idea is not being able to specialize generic types for certain arguments, but to provide a mechanism that can generate those types, and standardize the type templates used above.