combined return and if statement like ruby

[gregveres]

I was coming here to suggest a return if type statement and Github suggested a previous proposal from last summer.

I don't think the original poster on that proposal articulated the right solution, but one of the responses pointed out that Ruby has this construct already..

I guess I should do some research into how well this construct performs in Ruby, but I can say that my code is littered with things like this:

var value = somefunction();
if (value == null) {
    return <error>;
}

I believe that the code would be more readable if that code could look like this:

var value = somefunction();
return <error> if (value == null);

Thanks

[svick]

I think #1785 is very close to what you're proposing (but there are quite a few proposals for similar features, so I'm not surprised it's not the one you found).

I think the main issues with this proposal are:

1. if (value == null) return <error>; is already valid. If it's a company code style, or something like that, that doesn't allow you to write it on one line, then you should consider changing the code style, instead of changing the whole language.

2. It has a fairly high chance of being confusing. Consider a line like:

   return "a string literal, or another expression whose character count is fairly considerable" if (value == null);

   If the if is at the end of the line, I think it effectively hides the most important information about the line. And that's a problem, especially when you're scanning code, when trying to understand what it does.

[Austin-bryan]

Instead of

var value = somefunction();
if (value == null) {
    return <error>;
}

Just do

var value = somefunction();
if (value == null) return <error>;

Tada.

[AndrejZigmund]

We didn't add extension methods because people were stylistically opposed to static method calls.

I wonder why extension methods were added then? Was it some feature, that "you couldn't write certain code without" or was it "for convenience of developers" (which IMHO should be core reason of some modern language features)

[CyrusNajmabadi]

I wonder why extension methods were added then?

It was so that linq could be a pure syntactic transform. if you have a from x in y where x >= 0 we want to translate that syntactically to y.Where(x => x >= 0). As collections didn't have a .Where method on them, we needed a way to bridge that instance syntax to the actual static method declaration elsewhere.

We did not want linq to rewrite to be static calls because the entire point was that .Where would dispatch on the instance if possible (for example, for query providers), and that lambdas could become expression trees.

The point of Linq was to introduce syntactic patterns, that could still have unique domain semantics. Extension methods were necessary for that to complete the story so that vanilla collections (all the way down to IEnumerable<T>) would light up using the exact same system without the linq transform having to know anything about this part.

Was it some feature, that "you couldn't write certain code without"

yes. It was exactly that. We could not do Linq in a proper fashion without extensions.

[CyrusNajmabadi]

or was it "for convenience of developers"

Again, we have something convenient for developers. Choosing not to use it for stylistic reasons is not something we design around. After all, say we give you the feature you want. Then another person comes and says "i don't like either of those options. give me expr return if condition;. And now we have to go spend all the effort again because of their stylistic preferences.

[AndrejZigmund]

OK, that's very interesting. Thanks for discussion.

Guess nothing left, than just deal with it and "use the old ways".

[CyrusNajmabadi]

If tehre are other arguments in favor, then that's fine. I'm just calling out that style isn't part of the decision making process. So it's good to leave those justifications aside :)

[spydacarnage]

All the examples I'm seeing in favour of this are the form

if (something is null) return <error>

which already has a succinct short form.

The one scenario where I've previously found myself wishing for a short-hand is the reverse, where I have a string of "validate" checks at the start of a method and if any of them return an error, return that. That does now have a shortening thanks to pattern matching, but it's still needing extra variable declarations that aren't otherwise needed. For example:

if (checkOne() is Error errorOne) return errorOne;
if (checkTwo() is Error errorTwo) return errorTwo;
if (checkThree() is Error errorThree) return errorThree;
if (checkFour() is Error errorFour) return errorFour;

vs.

return checkOne() if not null;  // not suggested syntax, just for intention
return checkTwo() if not null;
return checkThree() if not null;
return checkFour() if not null;

[CyrusNajmabadi]

we have syntax for that:

var error = checkOne() ?? checkTwo() ?? checkThree() ?? checkFour();
if (error != null)
   return error;

[spydacarnage]

It's not perfect, as I sometimes need to do other work in between the calls, but as with many situations, it meets the majority case, and that's good enough.