The proposed solution reduces dramatically the entire code that a developer has to write, as there are many cases when one line if statement is required.

What if we fixed go fmt so you could write

if x, err = strconv.Atoi(a); err != nil { return }

It's two characters shorter than than, if that's important.

The issue i have is that the IDE i am using is automatically formatting all the if statements and is also folding by expanding the blocks most of the time. The issue I believe is the number of lines of code rather the 2 extra characters. Ideally would be "?"

Right, but if we’re talking bout chasing the language, something on the table for comparison should be changing go fmt to permit trivial if blocks to stay on the same line.

Whatever change is made (if at all), the IDE will have to change. So arguments about the IDE doing it wrong are moot.

I was just pointing that I believe most people including me think GO doesn't have proper ways to handle errors is mostly because GO requires brackets in if statements and IDEs are automatically expanding these blocks most of the time.

I don't see how this is significantly different from a single line if, other than being more complex #27135 and others

This has some similarities to #38151. Also to #32946.

My proposal was that using the proposed keyword "then" you can solve most error handling in a single line. Also for integrating this proposal I believe it requires adding one single regex expression for parsing the word "then" and expecting an instruction.

Most likely the community will fork golang and create a golang compiler that allows one liner as you guys simply don't want this. Something like a simpler version of Go+

@davecheney

You can't. That would cause huge swaths of unnecessary changes for any commit

Maybe change gofmt to allow following to stay on the same line:

if err != nil {{ return }}

Or when there is a comment:

if err != nil { return } //gofmt:inline

how about
if err != nil then return

@89z everybody hates the golang 3 liner error handling in big projects

I wrote about 16k LOC in golang in the last 2 months. I enjoy the language but the error handling is extremely verbose. I even looked for golang transpiler on the web. I found this https://github.com/lunixbochs/og

https://github.com/PandoraPay/go-pandora-pay

Regarding your examples, the "then' keyword would solve most of the issues above. Check this out.

re := regexp.MustCompile("some (pattern)")
if find := re.FindStringSubmatch("some input"); err == nil then  return find[1], nil
else then return "", errors.New("not found")

func blah() (*os.File, error) {
   if f, err := os.Open("something"); err == nil then return f, nil
   else then  nil, fmt.Errorf("call os.Open in func blah: %v", err)
}

Because I find golang very verbose, It makes me believe it is intended for very small projects, like scripts, or small servelet.

LE2: As I mentioned before, doing some code analysis, I found that about 18% of the LOC are the "infamous 3 line error handling". Taking in consideration the 3 line error handling is actually 3 lines it means that about 40% of the code is just error handling ... It means, there is something wrong with the golang three liner error handling

@89z i just want to have a one liner error handling. I totally believe that something must be done. I proposed one option "then" keyword. I don't care how it can be done we want one liner error handling :D .

i@89z that is not one liner error handling. The IDE I am using is unfolding by expanding these blocks most of the time. Also when committing on github, the LOC are expanded again. As far as I understood it is the gofmt that is doing this.

func two(name string) (f *os.File, err error) {
   if f, err = os.Open(name); err != nil { return }
   return f, nil
}

also this approach with
if f, err = func(); err != nil {return}

it is not that great because in case func() is also returning some value and error, the value is being propagated

I don't know how to disable gofmt in goland. If you tell me then I will disable it and I will never activate gofmt again. I only see that you guys received over 50+ proposals in all these years for different one liner error handling and all of them were refused for one reason or another.

To illustrate why gofmt is bad in practice... Just a random thing I was working on right now... and the reason why a real world one liner if statement and error handling is really useful.

select {
case newWork, ok := <-continueProcessingCn:
	if !ok {
		return
	}
	if newWork != nil {
		work = newWork
		listIndex = 0
		txMap = make(map[string]bool)
	}
case _, ok := <-suspendProcessingCn:
	if !ok {
		return
	}
	continue
}
if work == nil {
	continue
}
if len(txList) > 1 {
	sortTxs(txList)
}

select{
case newWork, ok := <- continueProcessingCn:
	if !ok then return
	if newWork != nil {
		work = newWork
		listIndex = 0
		txMap = make(map[string]bool)
	}
}
case _, ok := <- suspendProcessingCn:
	if !ok then return
	continue
}
if work == nil then continue
if len(txList) > 1 then sortTxs(txList)

22 LOC vs 15 LOC. A reduction of 31.81% LOC

@ibudisteanu Less lines of code do not mean more readable. You can write the whole program in one line if you insert the semicolons. gofmt was designed under the premise that your 22 LOC version is preferable to the 15 LOC version.

@fzipp I honestly believe that the 2nd option with 30% less lines of code is more readable that the 1st option especially when you have large projects.

@ibudisteanu Your variant tucks away what is, in my opinion, the most important information of a function body: where does the control flow change, what are the edge cases.

Based on the discussion above, and the emoji voting, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.