Proposal: return? — Soft or Conditional Return Statement

[hosseinjafari]

Summary

A proposal to introduce a new lightweight early-return syntax, return?, that allows methods to optionally return early when a non-null result is produced — eliminating redundant if (x != null) return x; checks.

Full detailed proposal attached below.

Proposal: return? — Soft or Conditional Return Statement

Author: Hoosein Jafari (By ChatGPT)
Status: Proposed
Language Version: C# (future)
Discussion: [TBD — GitHub Issue URL once created]

---

Summary

Introduce a new statement form return? <expression>; that allows a method to optionally return early only if the given expression produces a non-null result (or otherwise meaningful value).

This mechanism enables more expressive, cleaner, and safer early-exit flows without explicit null-checks in the caller method.

---

Motivation

In modern C#, conditional returns are common patterns, especially in validation, authorization, or multi-step methods where each stage may decide to return early.

Example (current C#):

public string HandleRequest(Request req)
{
    var auth = CheckAuth(req);
    if (auth != null)
        return auth;

    var validation = Validate(req);
    if (validation != null)
        return validation;

    return "Success";
}

This pattern is verbose and repetitive, obscuring the main control flow.
The developer’s intent (“return if something is produced”) is diluted by boilerplate code.

---

Detailed Design

Syntax

A new statement form is introduced:

return? <expression>;

It means:

“If the expression evaluates to a non-null value (or a truthy optional result), return that value immediately. Otherwise, continue execution.”

The expression must be type-compatible with the method’s return type.

---

Semantics

The compiler would conceptually translate:

return? expr;

to:

{
    var __temp = expr;
    if (__temp != null)
        return __temp;
}

This is purely syntactic sugar and introduces no new runtime behavior.

---

Nullable and Generic Return Types

If the method’s return type is nullable (T?) or an optional-like generic (Maybe<T>, Option<T>), return? naturally extends to these:

public string? GetResult()
{
    return? TryGetCachedValue();
    return? TryComputeValue();
    return "Default";
}

If neither method yields a value, the method simply continues execution.

---

Examples

Example 1: Validation Chain

public string ProcessRequest(Request req)
{
    return? CheckAuth(req);
    return? ValidateInput(req);
    return? CheckQuota(req);

    return "Request Accepted";
}

Each call either produces a response (early return) or allows execution to continue seamlessly.

Example 2: Simplifying Nested Logic

public string ProcessData(Data d)
{
    return? EnsureValid(d);
    DoProcessing(d);
    return "Done";
}

---

Control Flow Safety

• return? does not bypass finally blocks.
• It respects async/await semantics, identical to regular return.
• The compiler ensures the target method still satisfies definite assignment rules for non-nullable return types.

---

Optional Extension: continue; in Method Scope

An optional conceptual sibling, continue;, could act as “skip current path and return control to caller”, but this remains outside the scope of this proposal.
Future discussion could explore continue; or yield? variants for async and iterator contexts.

---

Benefits

Benefit	Description
Cleaner code	Removes repetitive if (x != null) return x; patterns
Improved readability	Expresses intent more clearly (“return if valid”)
No breaking changes	Fully backward-compatible syntax addition
Easy compiler support	Pure syntactic sugar, similar to ?. or ??=

---

Drawbacks

• May reduce explicitness for beginners.
• Adds another form of conditional return to learn.
• Needs careful design for non-nullable contexts to avoid implicit null handling.

---

Alternatives Considered

1. if-return expression

   if (var result = Validate()) return result;

   — existing but verbose.
2. Pattern matching approach

   if (Validate() is { } result) return result;

   — explicit but noisy.
3. Monadic/Optional types (Maybe<T>)
   — powerful but requires extra type wrapping.
4. Soft return operator (return?)
   — simplest, expressive, and clear.

---

Design Notes

• Compiler can implement this purely as syntactic sugar.
• Static analysis tools (nullable flow analysis) should treat return? as potential early exit.
• No change to runtime or CLR required.

---

Relationship to Existing Features

• Similar in philosophy to:
  • Null-conditional operator (?.)
  • Null-coalescing assignment (??=)
  • Pattern-based is not null checks
• Follows the language evolution trend toward expressiveness with safety.

---

Open Questions

1. Should the behavior be limited to reference types (null-based)?
2. Should the compiler treat default(T) as “empty” for value types?
3. How does this integrate with async Task<T> methods?
   (Likely identical translation with await semantics preserved.)

---

Conclusion

The return? statement offers a simple yet elegant improvement to everyday C# code patterns, reducing noise and improving intent clarity.

By introducing a soft return, developers can write cleaner, more expressive code without changing the underlying semantics of method control flow.

Authored by Hoosein Jafari
Date: October 2025
CSharp_ReturnQuestion_Proposal.md

[spydacarnage]

This was proposed only last week, and was rejected then, too.

[hosseinjafari]

Do you have that issue link?

[spydacarnage]

#2195

And there have been many dupes over time.

[hosseinjafari]

Thanks for the reference!

I’d like to clarify that while Discussion 2195 touches on optional returns for nullable types, this proposal introduces return? at any point in a method body, including nested conditionals and loops, allowing the caller to continue execution automatically if the returned value is null.

The behavior and use cases are therefore different and complementary.

[spydacarnage]

Hence why I also said "and there have been many dupes over time" - this is not the first time this exact thing has been proposed (you can search for it yourself if you need to see the rejection).

[hosseinjafari]

Thanks for pointing that out! I’ll review related discussions to better understand the overlap and differences.

[CyrusNajmabadi]

public string HandleRequest(Request req)
{
    var auth = CheckAuth(req);
    if (auth != null)
        return auth;

    var validation = Validate(req);
    if (validation != null)
        return validation;

    return "Success";
}

Can already be simplified as:

=> CheckAuth() ?? Validate() ?? "Success";

[CyrusNajmabadi]

@hosseinjafari I don't see how your feature here would help. You're not checking if something is null, and returning it if it is not. You're checking entirely different things, then creating Json instances to return back. So the hypothetical return? syntax wouldn't help here.

[hosseinjafari]

These examples are somewhat intricate and worth discussing. Should the method’s output be a boolean and the client receive the result at a higher level? Both yes and no—it depends on where the method resides. If the check for whether the auction is open occurs at the service level, the return value should be a boolean. A private control-level method that performs this check could instead return the main method’s output.

public async Task<JsonResult> BidToAuction(int id, decimal price)
{
    .
    .
    .
    return? await UserNotPaidToAuction(id);
    .
    .
    .
}

private async Task<JsonResult?> UserNotPaidToAuction(int id)
{
    if(! await _actionService.UserNotPaidToAuction(id))
        return Json(new { success = false, Msg = "..." });

  //magic happens here. We don't need return null or false to caller and compiler does this.
}

[hosseinjafari]

An even more complicated situation could be like this:

private async Task<JsonResult?> UserNotPaidToAuction(int id)
{
    if (! await _actionService.UserNotPaidToAuction(id))
    {
        if (await _accountSevice.HasCredit())
        {
           await  _accountSevice.PayForBidFromCredit(id);
           
           //Explicit soft return
            return?;

           //Or even (like loops), it'd possible to use continue keyword instead of "return?"
          //continue;
        }

        return Json(new { success = false, Msg = "..." });
    }

    //Implicit soft return. No need to this at method end.
    //return?;
}

[CyrusNajmabadi]

I don't know what a 'soft return' means.

[franchyd]

I think he's trying to describe a new syntax for coroutine like functionality to "soft return" (yield and continue in calling function) and "hard return" (yield and then return yielded value in calling function) But seems hard to read and needlessly complex.

[vit-h]

Hi everyone,

I want to share a real-world use case that demonstrates the value of return? in production codebases.

Current Reality

In codebases using the Result pattern for error handling, this appears thousands of times:

        ....
        
        var validatorResult = await validatorResult.ValidateAsync(cmd, ct);
        if (validatorResult.Error != null) return timeResult.Error;

        var timeResult = await timeEnricher.EnrichAsync(data, ct);
        if (timeResult.Error != null) return timeResult.Error;

        var subjectsResult = await subjectsEnricher.EnrichAsync(data, ct);
        if (subjectsResult.Error != null) return subjectsResult.Error;
        
        return DoMore(timeResult.Value, subjectsResult.Value);

Issues:

• 6 lines of boilerplate for 3 error checks
• Intermediate variables (e1, e2, e3) exist only to satisfy the compiler
• Happy path is buried under error handling

With return?

        ....
        
        var validatorResult = await validatorResult.ValidateAsync(cmd, ct);
        return? validatorResult.Error;

        var timeResult = await timeEnricher.EnrichAsync(data, ct);
        return? timeResult.Error;

        var subjectsResult = await subjectsEnricher.EnrichAsync(data, ct);
        return? subjectsResult.Error;
        
        return DoMore(timeResult.Value, subjectsResult.Value);

Benefits:

• 50% shorter line for null check and return (if (validatorResult.Error != null) return timeResult.Error; vs return timeResult.Error:)
• Clear intent: "Return this error if present"
• Variables remain available for happy path
• No noise variables needed compare to if (timeResult.Error is { } e) return e;

Why ?? doesn't help

@CyrusNajmabadi suggested ??, but it doesn't work when you need result values later:

// Can't use ?? - we need timeResult.Value below
return? validationResult.Error;
return? timeResult.Error;
return? subjectsResult.Error;
return DoMore(timeResult.Value, subjectsResult.Value);### Scale

This would eliminate 1000+ lines of boilerplate while improving readability.

---

Recommendation: The return? <nullable-expression>; syntax would provide immediate value for Result-based architectures.

[CyrusNajmabadi]

var validatorResult = await validatorResult.ValidateAsync(cmd, ct);
var timeResult = await timeEnricher.EnrichAsync(data, ct);
var subjectsResult = await subjectsEnricher.EnrichAsync(data, ct);
var error = validatorResult ?? timeResult.Error ?? subjectsResult.Error;
if (error != null) return error;

6 lines of boilerplate for 3 error checks

No boilerplate.

Intermediate variables (e1, e2, e3) exist only to satisfy the compiler

No intermediate varaibles

Happy path is buried under error handling

Happy path not buried. Note all the return? cases have the same problem, interspersing the happy path with the error handling.

[spydacarnage]

No intermediate variables

Just to play devil's advocate for a moment, error is still an intermediary variable.

Also, while the end result of that code may be the same, the execution may be different. For instance, validating the subjects (the third check) may be an expensive call that you only want to do if the previous checks succeeded. This approach removes that short-circuiting "fail fast" approach that is often desired these days.

[CyrusNajmabadi]

If I want to fall fast, then that's what an exception would be good for.

If I have a result that I want to return, and I want to short Circuit. Then that's what ?? Is good for :-)

[colejohnson66]

If you have an error, throw it. That's what exceptions are for.

[martin-steinhoefer]

Hi,

I do have a question about the type that is returned from the code snippet. What does that snippet return actually?

I think, the root cause of the boilerplate is usage of error objects to indicate failure - instead of using exceptions - which where designed those days to avoid such code. Usage of exceptions allows for non-local error handling (additional to local handling) - contrary to return codes - which must be handled all over the place immediately after the invocation took place.
Usage of return codes should be limited, as one gets the immanent pain on one side but does not get rid of exceptions - leads to two different ways to handle failure ( and no: one should not catch any exception and turn it into an error object).

I think C# already has a nice and clean way to deal with such cases. And for those who want otherwise, they could do otherwise...

[DaveNatalieTripArc]

I like null conditional returns, but I'd prefer this syntax.

return ?? somethingThatMightBeNull

I don't think we should have to use an Exception for an early exit, and there are other syntactical sugar things in the language to reduce the number of null checks that you need to do.