Separate class declaration

[acaly]

Description

Currently it seems to be difficult to separate the declaration and implementation of classes in C#. For example, if one writes a cross-platform GUI framework like Avalonia, the backends (D3D, OpenGL, etc.) need to provide a unified API. This is usually done with C# interfaces today, but there are limitations:

1. It introduces a level of indirection when calling the methods which the runtime might not be able to reduce (even you declare those classes as sealed, the runtime don't know whether other implementations exist). For small methods, reducing the indirection and inlining should give a big improvement.
2. Interfaces cannot be created directly with constructors (or even static methods, even with the new static abstract members, unfortunately) and must be created from a factory method on another interface, which significantly complicates API design.
3. Before accessing the internal data of an instance passed by the API user as an interface, there needs to be a cast to class, which is unnecessary if there is only one implementation.

So it would be great if we can have a feature to separate declaration and definition.

Proposed syntax

Definitions:

definition class Font
{
}
definition class Renderer
{
    public void DrawText(Font font, string text);
}
definition class Window
{
    public Window(int width, int height);
    public Renderer GetRenderer();
}

Implementations:

class D3DFont : Font
{
}
class D3D11Renderer : Renderer
{
    public void DrawText(D3DFont font, string text) { ... } //Parameter type is the implementation type.
}
class Win32Window : Window
{
    public Win32Window(int width, int height) { ... } //Constructor.
    public D3D11Renderer GetRenderer() { ... } //Returning the implementation type.
}

User of the library:

var window = new Window(400, 600); //Compile-time type is Window. Runtime knows this is Win32Window.
var renderer = window.GetRenderer(); //Compile-time type is Renderer. Runtime knows this is a D3D11Renderer.

Notes

1. Only classes can be supported (i.e., structs must not be declared in this way).
2. Exactly one implementation must exist in the runtime. Using a class without definition should throw. Loading another assembly with another set of implementation should also throw.
3. Like many other C# features proposed, there needs to be some runtime support, in this case to extract and validate an implementation table containing information on such classes from each loading assemblies.
4. It might look similar to shape, but shape is still for abstraction, similar to what interface was designed for, just more advanced. This features is different, because it's not an abstraction. It's more like a specification.

[bigredd0087]

It looks like what you want is abstract classes which already exist.

[acaly]

Abstract classes suffer from the same three problems as I have listed above.

[CyrusNajmabadi]

this feels like onr of the canonical cases for ref-assemblies. you ship the ref-assembly which people compile against. it has no impl. You then have the particular platform impls that are appropriately loaded at runtime.

[acaly]

Ref assembly seems to be the correct tool for this. Thanks!