Proposal: Shorter syntax for exposing sub-object methods

[LWChris]

Many composed classes and wrappers have the sole purpose of selectively exposing single members though forwarding. Currently, this can be quite a lot of code to write, especially if the class in question has a lot of overloads. A shorthand syntax for exposing sub-object methods would be very useful in many cases:

Current code:

public class Wrapped {
    /// <summary>Gets the length of the Bar.</summary>
    public int Length {
        get {
            // ...
        }
    }

    /// <summary>Lorem ipsum dolor sit amet.</summary>
    /// <param name="value">Consectetur adipisici elit.</param>
    public void Foo(sbyte value) { }

    /// <summary>Sed eiusmod tempor incidunt ut labore et dolore magna aliqua.</summary>
    /// <param name="value">Ut enim ad minim veniam.</param>
    public void Foo(byte value) { }

   // short, ushort, int, uint, long, ulong, ...
}

public class Wrapper {
    private readonly Wrapped m_Wrapped;

    public Wrapper(Wrapped wrapped) {
        m_Wrapped = wrapped;
    }

    /// <summary>Gets the length of the Bar.</summary>
    public int Length => m_Wrapped.Length;

    /// <summary>Lorem ipsum dolor sit amet.</summary>
    /// <param name="value">Consectetur adipisici elit.</param>
    public void Foo(sbyte value) => m_Wrapped.Foo(value);

    /// <summary>Sed eiusmod tempor incidunt ut labore et dolore magna aliqua.</summary>
    /// <param name="value">Ut enim ad minim veniam.</param>
    public void Foo(byte value) => m_Wrapped.Foo(value);

    // ...
}

Disadvantages:

• You write a lot of code that basically does nothing than calling other code that has the same signature.
• You have to copy the documentation (and <inheritdoc> doesn't work since this is not inheritance).
• Updates to the documentation will not be reflected in your code.

Proposal

Method referencing

public class Wrapper {
    private readonly Wrapped m_Wrapped;

    public Wrapper(Wrapped wrapped) {
        m_Wrapped = wrapped;
    }

    public int ref m_Wrapped.Length;
    public void ref m_Wrapped.Foo(sbyte);
    public void ref m_Wrapped.Foo(byte);
    // ...
}

This will automatically create forwarding members with the same signature and documentation as the referenced member. By changing public to e. g. protected you can modify the accessibility of the generated forwarding member.

Variants

There could be even shorter and more versatile/powerful syntax, but their usage bears risks:

Method group referencing

    public int ref m_Wrapped.Length;
    public void ref m_Wrapped.Foo;

Length and Foo look the same, but since "Foo" references a method group, create forwarding methods for all members of the method group.

Risk: if the wrapped class adds new overloads, this will also add new overloads to the wrapper. However, this would arguably be a desired behavior for many (most, even?) wrappers, and inheritance does the same (but not even limited to new overloads of existing functions) and it's not a problem.

Return type inference

    public ref m_Wrapped.Length;
    public ref m_Wrapped.Foo;

Create methods for all members of the method group and pass back their results.

Risk: while being useful in general for even shorter syntax, there are cases where changes to the wrapped object's API do not only change the API of the wrapper, but may vitiate the whole purpose of that wrapper. Imagine a "ReadOnlyWrapper" selectively forwards some void methods of a mutable instance using the public ref syntax. Now the wrapped mutable gets changed to a fluent interface. Suddenly, the ReadOnlyWrapper will expose the mutable object.

It is supposedly a very weird and rare scenario that can be easily avoided by using public void ref instead of public ref, but it's a risk worth noting nevertheless. Probably, using the syntax public dynamic ref instead of just public ref makes this more obvious.

= Choice of syntax =
I propose using the ref keyword. My reasoning was as follows: I definitely did not want to introduce a new keyword. Looking at existing keywords, these keywords seemed suitable to be generally relatable to the concept of call forwarding: abstract, as, base, delegate, implicit, interface, ref, using, and virtual. I ruled out abstract, delegate, implicit, interface, and virtual, since they are already used as keywords within classes. as would make sense for an alias, but writing a readable syntax without repeating 90% of the signature was impossible. base implies inheritance too much, when the concept at hand is actually composition, not inheritance. The only two remaining keywords were ref and using. Since using already has multiple meanings, and ref somewhat conveys the principle of defining a mechanism where you pass something in and get something out again, I chose ref. As mentioned earlier, ref is not a valid keyword on class level yet, so conflicts are impossible.

[PathogenDavid]

Rather than changing the language, this seems like a good application of source generators.

[AartBluestoke]

i think that a concise syntax for forwarding would aid tooling. I think that it would also aid development as forwarding is quite a common operation, however i believe method group expansion (1 member compiles into many members) is the realm of source generators, due to potential opaque binary breaking changes.

i doubt the language team would be happy with a feature that allowed upgrading a third party library (the source of the forwarded type) to be a binary breaking change - which any automated method group expansion feature would be.

[LWChris]

i doubt the language team would be happy with a feature that allowed upgrading a third party library (the source of the forwarded type) to be a binary breaking change

How would this introduce opaque binary breaking changes though? I would argue this syntax is not more risky than writing myEnumerable.Select(ThirdParty.Library.Method). Method group references are something C# already has. Every reference to a method group will be resolved to the actual methods at compile time, and if I write public void ref m_Wrapped.Foo in my code, that is the same as writing public void Foo(someType value) => m_Wrapped.Foo(value); for every someType. It's not like the compiled code will still contain a reference to a method group, it'll rather have been expanded to a well-defined set of actual functions in the wrapper, and a normal method call at every location I'm using the forwarding methods. It behaves the same as if I had written all of the forwarding methods by hand.

Sure, if I update the thirdparty library A and it adds a method which now makes any reference in my library B unclear, this will hit me at compile time. And if the issue is not in my code but in somebody else's code C who uses my library B, then they will have a compile time error when they try to recompile against my new library B. But the old binaries of C or B are not containing method groups anywhere, just calls to existing methods in B and A. So unless that method gets removed in A, B and C will work - and if A removes a method, code will break, no matter if I wrote all forwarding methods by hand or used a shorthand syntax.

[scottdorman]

@LWChris

and <inheritdoc> doesn't work since this is not inheritance

It does though if you use the <inheritdoc cref="..."/> syntax and point it to the correct member.

In your example, it would look like:

/// <inheritdoc cref="Wrapped.Length"/>
public int Length => m_Wrapped.Length;

I will say that the introduction of expression-bodied members has greatly reduced the amount of boilerplate noise we have to write.