Skippable return

[olugt]

UPDATE 2020-11-25 GMT+1:
For the sake of clarity, the main objective is how to return from a method without having to type lots of if code. It's not about handling error. Also, it is not about out parameter because an async method cannot use an out parameter. Hence, the "skippable return" idea. If tuple is not ideal, contributors should kindly suggest any viable alternatives.

MAIN DISCUSSION:
Please, in C#, can we have something like the following...

skippable return ProcessExists(username);

skippable return ProcessUnlockStatus(username, someOtherParameter);

return null;

...instead of...

var (doesUserExist, message_UserExistence) = ProcessExists(username);
if (!doesUserExist)
    return message_UserExistence;

var (isUserUnlocked, message_UserUnlockStatus) = ProcessUnlockStatus(username, someOtherParameter);
if (!isUserUnlocked)
    return message_UserUnlockStatus;

return null;

...where...

skippable return

...expects a tuple in the form of...

(bool someBoolean, object someObjectToBeReturned)

...and in my example, it is such that if isOk is false, the method should return. But that's just my use case. Another person may prefer to return when isOk is true. So, it depends on which way the eventual spec would choose.

Please, I really think it's great.

I had tweeted about the original text (already modified here) at...
https://mobile.twitter.com/OluGt_/status/1331292170230312960

[olugt]

The code is not intuitive but I had to come up with something to demonstrate what I am trying to say and keep the narration as short as possible.

[olugt]

I mean that the valid C# code is the way it is in the idea just for the sake of describing the idea. I'm aware the method names or intents may not sit well with a lot of people. But I had to type something as short as possible.

[HaloFour]

See: #3242

[olugt]

I AM SHOCKED❗❗❗

That is the answer❗❗❗

That is why I like to be understood. Thank you for staying with the argument and not giving up❗

I have checked it with an async method and it works❗❗❗

[olugt]

Please, I can't seem to get the URL to this answer. If you can, kindly respond with a URL to this answer so that I can post it on the tweets thread on Twitter, quoting your answer.

[canton7]

The link is on the text "17h ago" (or whatever the time is): #4173 (comment)

[olugt]

Thank you so much❗

[olugt]

Thank you so much, again, @HaloFour ❗❗❗ I should not forget to say it works for pattern-matching types too, just like anything else❗

if (ProcessSomething(username) is { Property1: 123, Property2: var prop2Value }) return prop2Value;

if (ProcessSomethingElse(username) is { PropertyBle: var propBleValue, PropertyBla: 456 }) { logger.LogSomething(propBleValue); return propBleValue; };

return null;

[olugt]

It should be noted that other scenarios of the use of return can cause modification to the idea.

For example, if no return value is applicable, making the return skippable can be by just supplying a boolean value like...

skippable return SomeBoleanCheck(username);

return;

[canton7]

From the snippet you posted, it looks you're doing error handling by passing bools around. If this is the case, the idiomatic way to do this in .NET would be using exceptions. Then you can write:

EnsureProcessExists(username);
LockProcess(username, someOtherParameter);

The functional approach would be to use a Result<TResult, TError> type instead of a tuple. There are some other discussions around adding some capabilities to the language to let you return if a Result<TResult, TError> contains an error in a syntax-efficient way (similar to e.g. Rust's ? or Swift's try): you'll have more luck adding your voice to those, although I don't think they'll get very far very soon.

[olugt]

I'm not passing error.

It only describes a scenario where I can return without using lots of guard code. So, maybe the use of tuple makes it somehow. But the main objective is how to return from a method without having to type lots of if statements. Hence, "skippable return".

[olugt]

Check the update I made to the idea, because some people thought it's about error handling.

[canton7]

My point about it being a bad version of Result still stands; go find one of those proposals.

[olugt]

The boolean (the first parameter in the tuple) does only one thing, which is to determine whether or not the method should return immediately right there. The second parameter can be any kind of object (not just string as used in my example) because throwing an exception is not always applicable when something doesn't go in a particular way, as an object may want to be returned instead. So, again, the boolean is strictly for determining whether to return or not.

Btw, I tried to search for the discussion you referred to but no search result came up. Also, it is not same as my idea, as I just explained.

[canton7]

I think it is the same as your idea. A Result<TResult, Error> contains a bool saying whether the operation succeeded. If it did succeed, it contains an (optional) result. If it failed, it contains a resulting error. Languages which use Result<TResult, TError> often have syntax to return straight away with the error if a result failed. So your idea is equivalent to a Result + syntax to return with the error part of the result if the result failed I think: it just uses a union type rather than a tuple.

Discussion on Result happened in the various disctriminated union proposals. There's a discussion on the "return if a result failed" bit here.

[canton7]

Also:

I tweeted about this at...
https://mobile.twitter.com/OluGt_/status/1331292170230312960

Mads replied:

I'm not a fan. It's too much of a special case to deserve its own syntax. Personally I think the Try...(out var ...) pattern does a good job here, and is much more general.

[olugt]

Nevertheless, that's why it's an idea. He simply expressed his view.