proposal: Go 2:

[krishnamraju3]

Author background

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  novice
• What other languages do you have experience with?
  C language

Related proposals

• Has this idea, or one like it, been proposed before?
  not sure, could not find anything similar from a google search
  • If so, how does this proposal differ?
• Does this affect error handling?
  yes, I think, the proposed solution avoid misunderstanding of which err is being returned.
  • If so, how does this differ from previous error handling proposals?
    not sure about previous error handling proposals, where can I find those?
• Is this about generics?
  I think no.
  • If so, how does this relate to the accepted design and other generics proposals?

Proposal

• What is the proposed change?
  I think, most will expect the compiler to throw error like: "result parameter err was declared both in inner and outer scope", when compiling below piece of code, because this can cause hard-to-debug issues:

` package main

import (
"errors"
"fmt"
)

func main() {
    fmt.Println(foo())
}
func foo() error {
        err := errors.New("foo err")
        if n, err := boo(); err != nil {
            fmt.Println(n)
        }
        return err
}
func boo() (n int, err error) {
        return 5, errors.New("boo err")
}`

• Who does this proposal help, and why?
  developers, this avoid misunderstanding of what is actually being returned from a function.
• Please describe as precisely as possible the change to the language.
  this is actually a compiler change,i.e, fail when there are multiple declarations of same variable in inner & outer scopes.
• What would change in the language spec?
  a compiler change wrt "Declarations and scope"
• Please also describe the change informally, as in a class teaching Go.
  I think this question is not applicable for this proposal
• Is this change backward compatible?
  I think this is not applicable for this proposal
  • Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.
    Show example code before and after the change.
  • Before
  • After
• Orthogonality: how does this change interact or overlap with existing features?
  I think this question is not applicable for this proposal
• Is the goal of this change a performance improvement?
  no
  • If so, what quantifiable improvement should we expect?
  • How would we measure it?

Costs

• Would this change make Go easier or harder to learn, and why?
  yes, this proposal avoid ambiguity/misunderstanding of developers.
• What is the cost of this proposal? (Every language change has a cost).
  not sure about the cost, as this is a compiler error, I think it won't cost any.
• How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
  may be vet.
• What is the compile time cost?
  may increase slightly.
• What is the run time cost?
  not applicable to runtime cost, as this is compiler change.
• Can you describe a possible implementation?
  compiler just have to throw error like: "result parameter err was declared both in inner and outer scope", when same variable is declared in inner and outer scopes.
• Do you have a prototype? (This is not required.)

[seankhliao]

Duplicate of #30321

[krishnamraju3]

Thanks!