[Discussion]: Argument Forwarding

[stevenwickers]

Proposal discussion: argument forwarding expression using ...

Summary

I would like to discuss a C# argument forwarding expression using ... inside invocation argument lists.

The goal is to make forwarding methods, local functions, and lambdas easier to write and safer
to maintain by allowing the current callable’s parameters to be forwarded into another invocation.

static void Forward(int x, string y)
{
    Target(...);
}

static void Target(int x, string y)
{
}

The intent is that Target(...) behaves as though the parameters of Forward were written explicitly:

Target(x, y);

Motivation

Forwarding methods are common in wrapper APIs, overload funnels, logging/decorator layers, adapter methods, local functions, and lambdas.

Today, forwarding requires manually repeating every parameter:

static void Forward(
    int id,
    string name,
    CancellationToken cancellationToken)
{
    Target(id, name, cancellationToken);
}

This repetition is easy to get wrong when parameters are added, removed, reordered, or changed to ref, out, or in.

An argument forwarding expression would let the developer express intent directly:

static void Forward(
    int id,
    string name,
    CancellationToken cancellationToken)
{
    Target(...);
}

Proposed behavior

For an initial version, ... would only be valid inside a normal invocation argument list.

Target(...);
Target(prefix, ...);
Target(..., suffix);

When used, ... expands to the parameters of the containing callable in declaration order.

static void Forward(int x, string y)
{
    Target(0, ...);
}

would behave like:

Target(0, x, y);

The forwarded arguments should participate in normal overload resolution and type inference.

Ref kind behavior

The forwarding expression should preserve parameter passing mode.

static void Forward(ref int x, out string y, in DateTime z)
{
    Target(...);
}

static void Target(ref int x, out string y, in DateTime z)
{
}

This should behave like:

Target(ref x, out y, in z);

Invalid cases

For a conservative first version, these should be invalid:

Target(x: ...);      // named forwarding
Target(ref ...);     // explicit ref on forwarding expression
new C(...);          // object creation
Target(..., ...);    // multiple forwarding expressions in same argument list

Open design questions

1. Should ... forward all containing parameters, or only “remaining” parameters based on position?
2. Should explicit arguments after ... be allowed?
3. Should ... be allowed in constructors or object creation?
4. Should multiple ... expressions be disallowed, as proposed here?
5. Is ... the right syntax?
6. Should this feature support attributes, indexers, delegates, or function pointer invocations, or only ordinary method invocations?
7. Should lambda/local-function forwarding be allowed?

Prototype

I have a local Roslyn prototype that implements this experimentally.

The prototype includes:

• DotDotDotToken
• ForwardArgumentsExpressionSyntax
• parser support for ... inside argument lists
• binder expansion before overload resolution
• preservation of ref, out, and in
• diagnostics for invalid contexts
• tests for:
  • lexing/parsing
  • basic forwarding
  • overload resolution
  • generic type inference
  • optional parameters
  • params
  • ref, out, and in
  • local functions and lambdas
  • invalid contexts
  • duplicate forwarding

I am not submitting the implementation as a PR yet because I understand substantial language features should be discussed first. I would like feedback on whether this direction is worth pursuing, whether the syntax/semantics are appropriate, and what design constraints should be considered before any implementation PR.

Thanks for taking the time to consider this idea. I would appreciate any feedback on whether this direction is worth exploring further.

[HaloFour]

IMO it feels like something better suited to a snippet expansion in an IDE than a language feature. I'd want to see and read the full expansion, not have to evaluate in my head how that will play out.

[stevenwickers]

Thanks, that readability concern makes sense.

The main reason I was thinking of this as a language feature rather than only an IDE snippet is that a snippet helps at the moment code is written, but it does not keep the forwarding call connected to the containing signature over time. If a parameter is added, removed, reordered, or changed from value to ref/out/in, the expanded call can drift from the wrapper signature.

The intended benefit of ... is that the forwarding relationship remains explicit and compiler-checked:

static void Forward(int x, string y, CancellationToken cancellationToken)
{
    Target(...);
}

instead of duplicating the parameter list:

static void Forward(int x, string y, CancellationToken cancellationToken)
{
    Target(x, y, cancellationToken);
}

That said, I agree the readability tradeoff is important. One possible constraint for the feature would be to limit it to simple forwarding wrappers where the containing parameters are nearby and visible, and to disallow multiple ... expressions or named/explicit ref ... forms. Another possibility is that IDE tooling could show inline hints or offer an expansion preview, similar to how inferred types or parameter names are surfaced today.

I’m interested in whether the maintenance benefit is enough to justify that tradeoff, or whether the community feels explicit expansion should always be preferred.

[TahirAhmadov]

In some cases, a readonly record struct is in order, then the set of parameters can be specified once and referred to many times.

[stevenwickers]

That makes sense. A readonly record struct or similar parameter object can be a good fit when the parameter set is truly a domain concept that deserves a name and can be passed around as one value.

The cases I’m thinking about are a bit different: forwarding layers where the parameters already belong to an existing API shape, and introducing a new wrapper type would either change the public API or add an extra abstraction only to avoid repeating the forwarding call.

For example:

static void Forward(int id, string name, CancellationToken cancellationToken)
{
    Target(id, name, cancellationToken);
}

could become:

readonly record struct RequestArgs(int Id, string Name, CancellationToken CancellationToken);

static void Forward(RequestArgs args)
{
    Target(args);
}

but that changes both the method shape and the target shape. That may be a good design when RequestArgs is meaningful on its own, but it is a heavier change when the goal is just to forward an existing signature.

So I agree parameter objects are a useful option in some cases. I’m mostly trying to explore whether there is value in a lighter-weight forwarding construct for wrappers/adapters/decorators where keeping the existing parameter list is intentional.

[TahirAhmadov]

It doesn't have to be a "domain concept" necessarily. If you have a "public" method which expects a certain set of parameters, but you then want to forward those parameters to a few "non-public" methods, you can define a "non-public" record which serves a purely utilitarian function of passing the parameters around. Yes you have to construct it once in your "public" method, but given it's passed around enough, that effort is worth it. On the other hand, if the parameters are only forwarded once or twice, that effort isn't warranted, but then again, in that case a language feature isn't warranted, either.

[stevenwickers]

That’s a fair distinction. I agree the record/parameter-object approach does not have to model a domain concept; it can be a private implementation detail used to pass a stable parameter set between helpers.

Where I still see a difference is that this changes the shape of the implementation. Instead of forwarding the existing callable’s parameters, the public method first has to materialize a new value and the private helpers have to accept that value:

public void M(int id, string name, CancellationToken cancellationToken)
{
    var args = new MArgs(id, name, cancellationToken);
    Helper1(args);
    Helper2(args);
}

That can be the right design when several helpers consume the same group. I agree with that.

The case I’m trying to explore is narrower: wrapper/adapter/decorator methods where the desired shape is still ordinary parameters, and the forwarding call is meant to stay coupled to the containing signature:

public void M(int id, string name, CancellationToken cancellationToken)
{
    Inner(...);
}

In that shape, the compiler can preserve the existing API surface, preserve overload resolution/type inference/ref-kind behavior, and avoid introducing an extra carrier type whose only purpose is to bridge one call.

The forwarding expression could also be combined with explicit arguments:

public void M(int id, string name, CancellationToken cancellationToken)
{
    LogAndCall("M", ...);
}

private void LogAndCall(string operationName, int id, string name, CancellationToken cancellationToken)
{
    // ...
}

which would behave like:

LogAndCall("M", id, name, cancellationToken);

That said, allowing explicit arguments before or after ... is an open design choice. A more conservative version could require ... to be the entire argument list:

Inner(...);

and reject mixed forms such as:

Inner(prefix, ...);
Inner(..., suffix);

Your point raises the key design bar: if this only saves typing in one or two calls, it probably is not enough to justify a language feature. The stronger argument would need to be about reducing signature drift in forwarding-heavy APIs while retaining normal method signatures. If that use case is not common or compelling enough, then an IDE/code-generation solution or parameter-object approach may indeed be the better fit.

[TahirAhmadov]

WRT signature drift, it's actually better to have record struct because then you know that a change to that record "automatically" propagates to all your methods. Whereas with listing the parameters out every time, if one of the methods gets a parameter list change (of any sort), suddenly you get a whole bunch of compilation errors, and you then need to go around and sprinkle that change to all the methods.

[hez2010]

The syntax looks quite confusing to me as by seeing ... only I have no idea about what it is forwarding.

Instead of using a ..., I think a better way is to specify what it is forwarding around the ..., i.e. params, so that in the future this can also be extended to scenarios other than parameters.

btw I personally prefer ... being placed in front of the identifier/keyword instead of as a suffix.

void Foo(int x, int y)
{
    Bar(...params);
    // alternatively Bar(params...);
}

[stevenwickers]

Thanks, that is helpful feedback.

I agree that bare ... has a readability cost because the reader has to know that it means “the current callable’s parameters.” A form like:

Bar(...params);

does make the forwarded syntax more explicit, and it leaves room for the syntax to grow beyond parameters if there are other forwarding concepts in the future.

I had started with bare ... mostly because I was thinking of it as an argument-list splice, similar to “insert the current arguments here.” But I can see the advantage of including a keyword so the construct explains itself better at the call site.

One question I’d want to think through is whether params is the right word, since C# already uses params for variadic parameters. It might be good because it points directly at parameters, but it could also be confused with params array behavior. Other possibilities might be something like:

Bar(...args);
Bar(...parameters);

or perhaps a more explicit form if the design should prioritize readability over compactness.

I also like the point about placing ... before the identifier/keyword rather than after it. That reads more like a spread/forwarding operation applied to the thing being forwarded.

So I think the broader design question is probably: should this feature be a terse forwarding marker, or an explicit forwarding expression that names what is being forwarded? Your suggestion makes a good case for the latter.

[Euan-McVie]

If I can suggest a potential inversion of flow use case.
In constructors, and especially for Records where parameter name mismatch can cause accidentally disconnected properties it would be useful to have this bi-directional.
record Derived(...base):Base(...params)
This allows an opt in to keep alignment of the shared Properties.

Aware this carries a fundamental issue of loss of control over your API surface as the base type could be elsewhere. With analyzers, IDE rename, and AI (reviews and coding) it maybe isn't as much an issue as it used to be.

Just thought I would throw this example as a potential use case, whether it adds or detracts from the argument.

[stevenwickers]

Thanks, that is an interesting use case.

I had been thinking about this mostly as invocation forwarding from the current callable into another call, but constructors and records do expose a related problem: keeping duplicated parameter/property shapes aligned across forwarding boundaries.

Something like:

record Derived(...base) : Base(...params);

is a much larger design space than what I was originally exploring, but I can see the motivation. Records in particular already make constructor parameters part of the public shape, so accidental mismatch between derived and base constructor/property names can be subtle and painful.

I also agree with the concern you called out: forwarding from a base type could couple the derived API surface to something outside its control. That seems like a stronger version of the readability/API-surface concern people have raised about ... generally.

For that reason, I think I would treat constructor/base-record forwarding as a separate but related scenario rather than part of the initial version. It may help clarify the broader problem space, though: there are several places in C# where the programmer wants to preserve alignment between two parameter/property shapes without manually repeating the whole list.

So I think this adds to the discussion as a useful adjacent use case, even if the initial feature, if it were pursued, probably needs to stay much narrower.

[stevenwickers]

Thanks everyone for the feedback so far. I've had some time to think through the points raised here, particularly around readability, whether the syntax should be more explicit than a bare ..., and keeping the initial scope narrow.

I still have my Roslyn prototype branch with the implementation and tests described in the original post, and I'd be happy to continue developing it.

I'm not sure what the appropriate next step is from here, though. Is this something that would benefit from being developed into a more formal C# language proposal/specification, or should I wait for additional feedback or interest before taking it further?

I also don't want to submit an implementation PR prematurely if the language-design direction hasn't reached that stage.

Any guidance on the appropriate next step—or whether this is unlikely to move forward as a language feature—would be appreciated.

[333fred]

See the doc on the process: https://github.com/dotnet/csharplang/blob/main/Design-Process.md. At this time, no member of the ldm has indicated interest in the idea, so it will not move further until that happens.

[CyrusNajmabadi]

Any guidance

What happens is that the language design team regularly meets and decides what areas to invest in. If this is something that is chosen, a "champion" from the team will be assigned to this discussion to drive it forward.

They would then act as the liason between you and the team to take this from an idea to a real proposal and implementation.

Thanks!

[stevenwickers]

Thank you, Fred and Cyrus.

Fred, thank you for pointing me to the language design process documentation. That gives me a much better understanding of how an idea progresses from a discussion into something the language design team may consider.

Cyrus, thank you for explaining how the championing process works and what would happen if the LDM decides this is an area worth pursuing. That clears up what I was unsure about regarding the next step.

I'll keep my Roslyn prototype branch and tests available in case there is interest in the idea in the future.

I appreciate both of you taking the time to provide the guidance and feedback. I've also really enjoyed digging into Roslyn and learning more about how C# language features are designed and implemented.

Thanks again!

[stevenwickers]

Thanks for the additional perspective. That's a good point regarding signature drift and the advantage a record struct can provide when the parameter set represents a cohesive piece of data. I think the distinction I'm still considering is between modeling parameters as data and forwarding an existing method's arguments as part of delegation. In the latter case, introducing a new type can change the API design simply to reduce the repetition involved in forwarding arguments. That said, your point about a record struct making changes propagate structurally rather than producing compilation errors across forwarding methods is a useful counterpoint, and I'll keep it in mind as I continue thinking about the motivation and tradeoffs for the proposal. Thanks for taking the time to share the feedback.

…

On Sun, Aug 30, 2026 at 10:51 AM Mr. TA ***@***.***> wrote: WRT signature drift, it's actually better to have record struct because then you know that a change to that record "automatically" propagates to all your methods. Whereas with listing the parameters out every time, if one of the methods gets a parameter list change (of any sort), suddenly you get a whole bunch of compilation errors, and you then need to go around and sprinkle that change to all the methods. — Reply to this email directly, view it on GitHub <#10308?email_source=notifications&email_token=AIBSSJ27WJTLIW7YXU5GXE35MQ5NVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGA3TSMBRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18207901>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIBSSJYEJKAY53R3B6UYUHD5MQ5NVAVCNFSNUABHKJSXA33TNF2G64TZHM3TKOJZGA4DQOB3IRUXGY3VONZWS33OHMYTANRSGY3DSOFBOYBA> . You are receiving this because you authored the thread.Message ID: ***@***.***>