[Discussion] Conditional Returns

[RandyBuchholz]

I was playing around where I was returning an early check result and didn't like having the return in the middle of the line. The intent was more important than the condition. I thought a conditional return would be nice. Then I though about the common practice of having a single return at the bottom of a method and wrap things in cases and ifs to support this. It adds a lot of wordiness. Even with multiple returns, sometimes these get wrapped in cases. A potentially cleaner coding style can be used if we had conditional returns. In the simplest form it just allows reversing the keyword and predicate:

// Instead of
if ( !_myObject.Exists() ) return await GetReturnStuffAsync();

// Intent comes first
return ( !_myObject.Exists() ) await GetReturnStuffAsync();

This can eliminate a lot of if's and cases

public (bool success, string result, object details)  Foo(Item inItem) {
   return ( !CheckItem(inItem) ) => (false, "CheckFail", null);

   var bar = DoWork();

   // Fail
    return ( !bar.success ) => (
        success : bar.success ,
        result : Convert.Result( bar.ActivityResult ),
        details : thing.where( s=>s.Details == bar.detailsKey )
    );
   
    // Pass
    return ( bar.success ) => (
        ...
        ...
        ...
    );
    
    // Default
    return (false, "fail", null);
}

You have to be aware of the order of things, but with the changes to switch with pattern matching, you have to now anyway.

[HaloFour]

The following is already legal C# syntax:

return (foo) => bar;

Even if you eliminated that ambiguity I don't see much utility in this proposal. All it seems to do is conflate conditions with returning values. In my opinion it doesn't improve readability of the code and the keystroke savings is minimal, at best.

[MgSam]

This syntax is confusing and I think it accomplishes exactly the opposite of your stated goal of putting intent first. if-then is logic 101, spilling part of the result outside of the if clause upends that.

[Thaina]

I was once propose syntax return if to work like you suggest in discussion about guard statement #138

[DavidArno]

Another use case for the match expression and supporting pattern matching on tuples:

public (bool success, string result, object details)  Foo(Item inItem) =>
    (CheckItem(inItem) is var result && result, result ? DoWork() : default) match (
        case (false, _) : (false, "CheckFail", null),
        case (_, bar) when !bar.success: (
            bar.success,
            Convert.Result( bar.ActivityResult ),
            thing.Where(s=>s.Details == bar.detailsKey)),
        case (_, bar): (
            ...
            ...
            ...)
    );

(ignored the "default" as that's unreachable)

[twojnarowski]

I see some issues and discussions and they seme to point to this one as the "original".
What do you think about creating a simple Guard Clause as a part of the C# language?
Currently Guard Clauses have to be written like this:

if(argument < 0 )
{
    return;
}

I think it would be nice to be able to write it like this:

return if argument < 0;

This is different from:

 if (argument < 0) return;

Because:

• is doesn't read as naturally.
• it is not visible from the first word that this is a guard clause with return statement, and thus not as readable
• it will throw a suggestion/warning for people who use csharp_prefer_braces = true in .editorconfig

We already have the same improvement on the basis of ArgumentNullException.
BEFORE:

if(argument is null)
{
    throw new ArgumentNullExcetpion();
}

NOW:

ArgumentNullException.ThrowIfNull(argument);

So it would be concise - Throw If Null, Return If Null

[HaloFour]

See: #1785 (comment)

Adding a second form for the sake of stylistic preferences would not be a good use of resources. The existing syntax already works fine and is no less succinct.