• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  intermediate

• What other languages do you have experience with?
  Java, C#, Javascript, PHP, Python, C++.

• Would this change make Go easier or harder to learn, and why?
  Only slightly harder as it is largely just syntactic sugar and is fairly easy to read and recognize.

• Has this idea, or one like it, been proposed before?
  There have been many error handling proposals, so I'm sure there have been similar ones, but none quite like this one I believe.

  • If so, how does this proposal differ?
    Many of the other proposals either require the addition of a keyword/identifier in Go (which has backwards compatibility issues),
    attempt to add subtle syntax changes (such as "?") to change the flow or behavior of a program, or behave very differently than
    typical Go behavior. This proposal attempts to avoid all of those issues.

• Who does this proposal help, and why?
  Every Go user. It helps cut down on ugly bloated code, and makes for a clear and concise line of error handling.

• What is the proposed change?
  I propose that the compiler generate the commonly used err := Func(); err != nil

  • Please describe as precisely as possible the change to the language.
    Compilers need to be changed to recognize an if following an assignment operator and generate the same compiled code as it
    would in the case of if err := Func(); err != nil

  • What would change in the language spec?
    This behavior would be documented under if statements

  • Please also describe the change informally, as in a class teaching Go.
    Currently if one would like to handle an error in the case of a method or function that returns multiple values, a developer is
    generally required to write five lines of code: one for variable assignment, on for an if statement checking if the error is nil, one for
    the opening curly brace, one for the body of the if statement, one for the closing curly brace. This proposal would, in many cases,
    mean those five lines are collapsed into one.

• Is this change backward compatible?
  I believe so.

  • Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.

• Show example code before and after the change.
  Before change

func SaveFavoriteColor(personID int, color string) (Person, error) {
  person, err := PersonByID(id)
   if err != nil {
      return err
   }

  person.FavoriteColor = color
  if err :=  SavePerson(person); err != nil {
    return err
  }
  // Trigger some event...
  return person, nil
}

After change

func SaveFavoriteColor(personID int, color string) (Person, error) {
  person := if PersonByID(id); return
  person.FavoriteColor = color
  if SavePerson(person); return
  // Trigger some event...
  return person, nil
}

• What is the cost of this proposal? (Every language change has a cost).
  Work will have to be done on the compiler. I'm not familiar with the process, but I'm should it would not be particularly easy.

  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
    All of them.

  • What is the compile time cost?
    Should be negligible.

  • What is the run time cost?
    No greater than a classic if err != nil check is today.

• How would the language spec change?
  Added example and explanation under if statements.

• Orthogonality: how does this change interact or overlap with existing features?
  Totally orthogonal.

• Is the goal of this change a performance improvement?
  No

  • If so, what quantifiable improvement should we expect?
  • How would we measure it?

• Does this affect error handling?
  Yes

  • If so, how does this differ from previous error handling proposals?
    Does not introduce any new keywords and reads very similarly to what we have today.

• Is this about generics?
  No

  • If so, how does this relate to the accepted design
    and other generics proposals?