Proposal: Support inline "if" statement syntax

[andreynering]

This is a brainstorming idea that came from #32825 (comment).

To be honest, I'm not sure if a agree with my own proposal, since it goes against some Go conventions, which disallow one-line-ifs (#27135) or the ternary operator, for example.

Even then, I think it's worth posting the idea here and raise some discussion.

---

Proposal

I propose that Go could allow inline if statements, just like Ruby does. This means that a code like this:

if value < 0 {
	value = 0
}

Could be written like this:

value = 0 if value < 0

Or, to give a more common example:

if err != nil {
	return errors.Wrap(err, "oops")
}

Could be written as:

return errors.Wrap(err, "oops") if err != nil

Some experiences from Ruby

On the Ruby world, inline if statements are used a lot. Some Rubysts think inline if`s shouldn't be used for non-return statements, though, for a similar reason why Go requires blocks on if statements: it makes it harder to follow code paths.

Based on that, it's also a possibility to only allow inline if on return statements:

// this would work
return foo.thing() if foo != nil

// this would raise a compiler error
foo.doSomething() if foo != nil

This restriction may prevent users to misuse this feature. Requiring a return in the beginning of the line would mitigate the raise on complexity while reading code searching for code paths.

Talking about errors

While this proposal has no relation to errors per se, it's true that the most common use case would be reducing the number of lines of code required to do error handling. In theory, in most cases this would allow 1 line to check + return an error instead of 3.

Pros

I think this proposal is way saner then #32437 which proposes the try built-in:

• try is black magic, and will be likely very confusing for beginners, while return is clear
• try is implicit, returns are explicit
• try disallow doing anything different than just returning the error, while with a plain return ... if people still have control to return a wrapped error or to modify the if statement:
  • return err if err != nil && err != context.Cancelled

I also think this is better than most errors proposals out there (including handle, etc).

Cons

• Harder to follow code paths, since if blocks are easier find while scanning code
• Can encourage programmers to write long lines (80+ characters) which reduces readability
• This breaks with existing Go conventions (but not more than try or handle, IMHO)

[henvic]

if err != nil return err

Why would your proposal be better than this example?

I don't like either, though.

[networkimprov]

Would it also allow single-line case, for, else, var () ? I'd like them all, please ;-)

See also #32611 which suggests: on err, <single_statement>

[lootch]

Well, the obvious sequitur seems to me only a little stretch to Go syntax; not beautiful, but that is in the eye of the beholder:

return err != nil; arg1, arg2, arg3, fmt.Errorf("failed: %v", err)

as in - for the case in point:

return err != nil; err

Which then might just lead to the totally heretical:

return arg1, arg2, arg3, fmt.Errorf("failed: %v", err); err != nil

and an incompatible idiom for returning the now "special" error argument:

func action(a int) (arg1, arg2, arg3 string; error) { ... }

(note that I intentionally omitted the "err" return argument name to suggest that the elements either side of the semicolon may be treated differently), but that is starting to look like an unsightly mess.

Also, maybe the return needs parentheses to "escape" the semicolon:
return (err != nil ; arg1, arg2, arg3, fmt.Errorf("failure: %v", err))

or

return (arg1, arg2, arg3, fmt.Errorf("failure: %v", err); err != nil)

I leave that to the referees.

Well, one needs to turn every stone...

[andreynering]

if err != nil return err

Why would your proposal be better than this example?

@henvic I never saw a language that allow that. IMO that's harder to read, since you don't have a keyword to separate the if statement to the rest of the code. Yes, you have return, but the inline if could be used for anything, so this would look strange:

if value < 0 value = 0

Having the if after ensure you have the if to separate the code from the check. Ruby also does that.

Would it also allow single-line case, for, else, var () ? I'd like them all, please ;-)

See also #32611 which suggests: on err, <single_statement>

@networkimprov I disagree with supporting inline else and for, I think that would hurt too much the readability.

About inline case or var, I'm not even sure what you mean here.

Well, the obvious sequitur seems to me only a little stretch to Go syntax; not beautiful, but that is in the eye of the beholder:

return err != nil; arg1, arg2, arg3, fmt.Errorf("failed: %v", err)

[...]

@lootch This falls in the same problem other proposals do, it more complicates then simplify things. That statement is less readable than a plain if statement, and I'm sure it could be confusing to new Gophers.

Inline ifs are just code, as we've already been writing, but inline to save a few lines of code.

[mvdan]

If you really wanted to collapse error checks into a single line, a much smaller change would be for gofmt to allow:

if err != nil { return err }

That opens its own list of questions, such as "what about for". But at least it doesn't introduce new syntax.

[networkimprov]

@mvdan, ppl keep repeating that, but it's not actually trivial.

if err == io.EOF { continue }     // if this
else if err != nil { return err } // why not this?

if t { x() } else { y() } // or this?
v := a; if t { v = b }    // or that?

And would the new go fmt rewrite much existing error code?

[mvdan]

I'm not saying it's a good idea. I'm saying that introducing new syntax generally has a higher cost.

[networkimprov]

Generally. But in this case, probably not.

[alanfo]

I've always been an advocate of go fmt allowing if statements which contain a single statement to be written on one line. These are very common and are often written like this in many other languages.

However, I'd leave it at that as doing more would open up a can of worms. In particular, I wouldn't allow it if there was an else clause and I wouldn't allow it for for statements either.

[andreynering]

However, I'd leave it at that as doing more would open up a can of worms. In particular, I wouldn't allow it if there was an else clause and I wouldn't allow it for for statements either.

I think that's the point: by having the inline if we could keep the current behavior of gofmt, disallowing single line for else and for and other usage like that.

To be honest, I'm fine with our current state, and have upvoted #32825 to reflect that. 🙂

But if we're going to make a change, I think it may be worth paying the cost to have a better and flexible syntax. A lot of other proposals also requires deeper changes, but this one is simpler.