One problem in your suggest:

If follow three cases in the same project, there will be a burden for the code reader and make it harder to copy and paste small part of code between files:

• rename io.Reader to IOReader in A file
• rename io.Reader to IoReader in B file
• use it with io.Reader in C file

@bronze1man Thank you, but I don't think that is a problem.

Related to #29036.

You can get a similar effect by writing, after the imports,

type IOReader = io.Reader

(For a function, use a var. Admittedly there is no simple way to alias an exported package-scope variable, but those are not commonly used.)

The requirement of writing a package name is not a major complaint about Go. In fact, many people think it is a feature. I'm not sure it's worth changing the language to add a shorter way of doing something that you can already do, and that not a lot of people want to do anyhow.

Speaking only for myself.

@ianlancetaylor Thank you. But I don't think it is a feature and the shorter way of coding is great.

Maybe it would be better to just allow omission of package name for all symbols that can be resolved unambiguously. Like so:

package main

import (
    "fmt"
)

// this shadows fmt.Print
func Print(x string) {
}

func main() {
    Println("Hello world") // instead of fmt.Println
    Print("local") // this package's Print is used
    fmt.Print("import") // package is specified explicitly
}

@yekhlakov Hello, I like that too. But trust me they will never let that happen!

As discussed above, there are other way to do this. We don't need a new syntax for it. And this proposal does not have strong support based on emoji voting. Therefore, this is a likely decline. Leaving open for four weeks for further comments.

There were no further comments.