Structural Typing keyword and associated compiler checks (Structural Typing Yet Again...)

[davidwhitney]

One of the restrictions that C#'s nominal type system has is that it forces people to wrap and convert matching concrete types and frequently hand roll adapters between types where they structurally match the requirements of other use cases.

Acknowledged Prior Discussions

I'm aware that there have been a number of swings at structural typing in C# over the years but I'm unaware of a discussion that matches this suggestion.

Prior art includes:

This is very similar to the goals of the Roles proposal, but a different approach to the problem

Ref: Roles and extensions

This also has similarities to extension types, where users could define an extension style mapping between types in their codebase

Ref:

• NET Announcements and Updates from Microsoft Build 2024
• But they didn't make it

Other discussions

• Working with untyped structured data in C#
• Interfaces are implemented implicitly

The purpose of this discussion is to discuss if a keyword-based approach might be lower ceremony and simpler implementation.

Problem

This process is often error prone or relies heavily on third party libraries - AutoMapper for DTOs, Mocking libraries, or the proliferation of mapping overloads just to coerce data-types.

I speculate we could enhance the language with a new or enhanced keyword to remove entire categories of package use and "glue code" without sacrificing safety.

Proposal - A "trust me bro" structural typing keyword + checks

In the following examples I'm going to use the invented keyword structurallyIs.

I think we could perhaps use the existing is/as keywords to the same end, but for clarity here I'm using an invented keyword to highlight what could work without potentially confusing the examples.

The key outcomes are:

• When two types structurally match, using a keyword you can tell the compiler to verify that they match

• When a strict subset of the class members are used, a narrower implementation can be provided and the compiler should verify only the implemented members are used by the calling code

I speculate this could be achieved by doing code gen of adapter classes (maybe "AutoAdapters" as a language concept), or some duck-type compiler trickery (maybe the receving type grows an object taking overload at compile time or something).

Some examples:

1. User defined function specifies an interface that third party types don't implement

class SomeThirdPartyType
{
    public int Value { get; set; }
}

interface ISomething 
{
    int Value { get; set; }
}

class CodeInMyCodebase
{
    public static void DoSomething(ISomething target) 
    {
        ...
    }
}

//  Current usage

var instance = new SomeThirdPartyType { Value = 1; };
CodeInMyCodebase.DoSomething(dto); // no compile

// To use an instance of SomeThirdPartyType I have to 
// either convert it

var instance = new SomeThirdPartyType { Value = 1 };
var mapped = new One { Value = instance.Value; };
SomeThing.DoSomethingWithOne(mapped);

// Or wrap it
class Adapter(SomeThirdPartyType src) : ISomething 
{
    public Value => src.Value;    
}

var instance = new SomeThirdPartyType { Value = 1 };
var adapterInstance = new Adapter(instance);

SomeThing.DoSomethingWithOne(adapterInstance);

// Suggestion:

var instance = new SomeThirdPartyType { Value = 1 };
SomeThing.DoSomething(instance structurallyIs ISomething);

2. Two classes "match", but receiver requires one of them, even when the developer knows at design time they are equivalent

class One
{
    public int Value { get; set; }
}

class Two
{
    public int Value { get; set; }
}

class SomeThing
{
    public static void DoSomethingWithOne(One target) 
    {
        ...
    }
}

// Current Usage
var one = new One { Value = 1 };
var two = new Two { Value = 1 };

SomeThing.DoSomethingWithOne(one); // works
Something.DoSomethingWithOne(two); // fails

/*
    It'd be nice if the second example would work because the developer
    understands the type has the same semantic meaning.

    This is a common scenario in layered architectures with many
    request / response objects or DTOs.

    The solution here is often libraries like AutoMapper, or 
    reams of messy assignment code that's the source of frequent
    bugs.
*/

// Suggestion:

var two = new Two { Value = 1 };
var asOne = two structurallyIs One;

Something.DoSomethingWithOne(asOne);
Something.DoSomethingWithOne(two structurallyIs One); // trust me bro

3. Receiving class depends on an interface that calling code uses a narrow subset of

// Entire mocking frameworks exist to mostly solve this problem

interface ISomething 
{
    public void Foo();    
    public int Bar();    
    public void Baz();
}

class CodeInMyCodebase
{
    public static void DoSomethingWithOne(ISomething target) 
    {
        // Only uses a strict subset of the interface
        var value = target.Bar();
        // ... do something with value;
    }
}

// Current Usage
// Mock it.

var mock = new Mock<ISomething>();
mock.Setup(x => x.Bar()).Returns(1);
SomeThing.DoSomethingWithOne(mock.Object);

// Or Stub it
class MyStub(int value) : ISomething
{
    public void Foo() => throw new NotImplementedException();
    public int Bar() => value;
    public void Baz() => throw new NotImplementedException();
}

var stub = new MyStub(1);
SomeThing.DoSomethingWithOne(stub);

/*
    It'd be nice that instead of having to provide full implementations
    of the interface for a "traditional home rolled mock", you could just
    implement the strict subset of requirements and the compiler could verify
    your usage was logically correct.
*/

// Suggestion:
class ClassThatImplementsOnlyTheUsedSubset
{
    public int Bar() => 1;
}

var existingInstance = new ClassThatImplementsOnlyTheUsedSubset();
SomeThing.DoSomethingWithOne(existingInstance structurallyIs ISomething);

// There are other possible answers to this problem but this feature fits.

Thoughts

Most of these scenarios apply when the developer doesn't have the ability to modify either the target or destination types.

This is common when:

• Using third party libraries
• Mocking and stubbing other components
• During tricky version resolution scenarios with package management

I see these scenarios often in large scale enterprise apps and think this could be a great unlock for the language.

I think this is only a "good proposal" if the compiler is able, at compile time, to still verify the useage of these kinda duck-like structural type matches. The community is often fearful of anything that even looks like dynamic typing, and this should explicitly be called out as "not that thing".

Existing behaviour effectively is unchanged and the surface area of the suggestion feels quite contained.

Prior Art

I believe Go can do this today, transparently and without keywords, but that feels a little too radical for the language norms of C#

[ufcpp]

#9094 #1647 #5863 #5849

[davidwhitney]

Good catch, yes, those also 👍🏻

[HaloFour]

I expect this kind of functionality will come about through the exploration into extension implementation. You would still have to declare that extension, but it's possible that the compiler could automatically wire up all of the required members if they already exist or could be satisfied through other extensions. Some members of the team have expressed a preference in wanting that to be explicit, like trait implementations in Rust. However that would only work to provide an implementation to an interface.

[HaloFour]

If you're looking for automapping capabilities (which is probably the only way you'll get something like proposal 2), this is something you could already achieve through source generators today through something like a helper method which is then synthesized as an extension method:

// you write
Two two = one.MapToTwo();

// source generator emits
public static class OneExtensions {
    public static Two MapToTwo(this One one) {
        return new Two() { Value = one.Value };
    }
}

Looks like such a project already exists: https://github.com/riok/mapperly

[davidwhitney]

That's an interesting project - there's a cognitive load leap to move towards source generators for a lot of the folks in enterprise who have these kinds of mapping needs (obviously anecdotal, but they scare a lot of people). I don't think "we have source generators for mapping" is really an improvement though because there's a category of complexity indirection over existing "in-the-source" library implementations.