#2195

And there have been many dupes over time.

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.

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).

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

@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.

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.
}

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?;
}

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

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.

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.

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 :-)

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

Exceptions are expensive,
We use the result object pattern and stop on the first failure.
And yes, subjectsEnricher queries the DB, so I want to call it last.
Thanks @spydacarnage for 100% true comment.

Exceptions are expensive

Exceptions are expensive only if it happens. Exceptions makes non-exceptional path cheaper.

I think what is important here is to provide the cases demonstrating why this is important and why existing alternatives are not adequate. Currently, all the use cases shown have very effective alternatives already in the language.

What are the semantics of this code:

return? throw EnsureAuthenticated(request);
return? throw ValidateInput(request);

If Inner methods raise exception, We should use something like this:

try
{
   EnsureAuthenticated(request);
   ValidateInput(Request request)
}
catch(AccessDeniedException ex)
{
   throw;
}
catch(ValidationException ex)
{
   throw;
}
catch(Exception ex)
{
   _loger.Log(ex);
   throw new UserFirendlyException();
}

catch(AccessDeniedException ex)
{
   throw;
}

Why are you catching the exception only to throw it?

Why that, instead of:

catch(Exception ex) when (ex is not AccessException and not ValidationException)

catch(AccessDeniedException ex)
{
   throw;
}

One should be aware, that there actually is a very important difference between catching and just re-throwing an exception and letting it just fly.

Having an exception catched actually invokes all captured finally blocks before the catch block is entered. That is sort of a guarantee that those blocks are executed in a timely manner close to the point in time the exception was thrown.

When the exception does not get catched after all, the runtime delegates to the unhandled exception handler of the app domain - which can decide to fail fast (anyone with access to it can overwrite it) - which would circumvent all finally blocks not invoked yet.
Anyway, handling an exception there will invoke the finally blocks at a point in time far away from the time the exception was thrown.

However, that may not have been the intention of the OP.