Proposal: Syntactic Sugar in C# for Forwarding Parameters

[Leucist]

Idea Overview

The idea is to introduce a new syntax in C# that allows developers to create wrapper methods without having to explicitly declare the parameters again. This would enhance code readability and reduce redundancy, especially when dealing with methods that simply forward calls to other methods.

Proposed Syntax

The proposed syntax could look something like this:

public object A(...) => _service.B(...);

In this case, the ... would automatically infer the parameters from the method being wrapped, allowing for a cleaner and more concise method definition.

Consideration of Options

I have considered three potential example scenarios for how this could work with lambda operators or plain methods:

1. A(...) => _service.B(...);
   This option may not be applicable for methods that have overloads. For those, we could use the second option:

2. A(...) => _service.B( /*specific params*/ );
   This ensures the correct method will be called.

3. WrapA(...) {}
   In this case, the method body must contain a pairing "..." in some method call.
   Could look something like this:

   WrapA(...) {
       // * Do stuff *
       a(...);   // or "return a(...)" could be used, if needed.
   }

Benefits

• Reduced Redundancy: Eliminates the need to repeat parameter types and names, making the code cleaner.
• Improved Readability: Simplifies the method signature, making it easier to understand the purpose of the wrapper.
• Less Error-Prone: Reduces the chances of mismatched parameter types or names between the wrapper and the original method.

---

Personal Experience and Invitation for Discussion

While implementing a caching system for mathematical operations in my project, I initially used a simple wrapper for a method and thought that adding such syntactic sugar could be quite convenient. This is a small detail that may not significantly change the usual development process, but it could simplify certain routine tasks.

I want to propose this idea as a concept for potential syntactic sugar, but not to push it rigidly. Instead, I encourage the community to engage in open discussion. I would be glad to hear both suggestions as well as concerns – if anyone notices a significant oversight regarding this novelty.

[TahirAhmadov]

The scenarios 1 and 2 can be accomplished today with a source generator - just decorate _service with an attribute, and make your SG write all those methods.

[Leucist]

Hi Tahir,
Thanks for you reply! I appreciate your suggestion about using source generators to achieve scenarios 1 and 2. However, I find it a bit complex compared to the proposed syntactic sugar, which aims to merely simplify the process.

Could you please elaborate on your idea? Maybe you could provide an example or reference a similar implementation? From my understanding, it seems like it might complicate things rather than simplify them, which is the opposite of what the proposed syntax aims to achieve. Feel free to correct me if I misunderstood anything!

Looking forward to your clarification!

[HaloFour]

A source generator could emit the source that wires up the delegation to the wrapped instance, e.g.:

public partial class Wrapper {
    [DelegatedTo]
    private ServiceA _service;
}

// source generator emits
public partial class Wrapper {
    [Generated]
    public void A(int x, int y) => _service.A(x, y);
    [Generated]
    public string B { get => _service.B; }
}

That generator could offer additional configuration for policy using attributes or other means, too, so that you can control which members are delegated, etc.

[Leucist]

I think I got what you meant. Thank you all for your insights and HaloFour for the detailed explanation regarding source generators :)

It seems that the use of source generators might require prior knowledge of the methods I want to wrap, which feels limiting. I could see the potential for creating a library with source generators, but that strays from the idea of syntactic sugar aimed at simplifying method signatures as I see it.

All in all, this discussion has led me to note that my proposal generally leans more towards simplifying parameter forwarding rather than method wrapping (it may be better to edit the issue title for better clarity). I appreciate the discussion however. Your responses allowed me to explore new possibilities I haven't really considered before. Thank you once again:)

[TahirAhmadov]

It seems that the use of source generators might require prior knowledge of the methods I want to wrap

The source generator can inspect the available members. When it sees the attribute like in @HaloFour example, it looks at the type ServiceA and sees which members are available for wrapping, and generated wrappers accordingly. Like he said, you can fine tune the behavior by specifying which methods you want to wrap (a string array parameter to attribute), or which types of members you'd like (an enum parameter to attribute), or these can be properties of the attribute so you can optionally use different ways to filter the members.

public partial class Wrapper {
    [DelegatedTo(MemberType.Method, MemberNames = [nameof(ServiceA.A)])]
    private ServiceA _service;
}