Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: list symbols that don't require package name #33070

Closed
UFOXD opened this issue Jul 12, 2019 · 10 comments
Closed

proposal: Go 2: list symbols that don't require package name #33070

UFOXD opened this issue Jul 12, 2019 · 10 comments
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal Proposal-FinalCommentPeriod v2 An incompatible library change
Milestone

Comments

@UFOXD
Copy link

UFOXD commented Jul 12, 2019

Problem:

In many case, the last word of the import path is not the real package name. So, it is kind of confusing here ! And write the package name over and over is not the best way to write or read code.

So I bring a proposal:

Proposal1:

import (
	"bufio"
	"encoding/binary"
	"fmt"
	"hash/adler32"
	"io" {Reader IOReader} //Give a new name
	"os"

	"github.com/hashicorp/raft" {RPCHeader, WithRPCHeader} //import multi 
)

No new keywords come in, no break code.

Proposal2:

Proposal1 is probably confusing and not accepted commonly.

import  "bufio"
import 	"encoding/binary"
import 	"fmt"
import 	"os"
import 	"hash/adler32"
import  {Reader as IOReader} from  "io"  //Give a new name

import  {RPCHeader, WithRPCHeader} from "github.com/hashicorp/raft" 

This is totally copied from TypeScript

@bronze1man
Copy link
Contributor

bronze1man commented Jul 12, 2019

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

@rocket049

This comment has been minimized.

@UFOXD
Copy link
Author

UFOXD commented Jul 12, 2019

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

@UFOXD UFOXD changed the title Enhance the import for Go2 proposal: Go2 Enhance the import Jul 12, 2019
@gopherbot gopherbot added this to the Proposal milestone Jul 12, 2019
@ianlancetaylor
Copy link
Contributor

Related to #29036.

@ianlancetaylor ianlancetaylor changed the title proposal: Go2 Enhance the import proposal: Go 2: list symbols that don't require package name Jul 12, 2019
@ianlancetaylor ianlancetaylor added v2 An incompatible library change LanguageChange Suggested changes to the Go language labels Jul 12, 2019
@ianlancetaylor
Copy link
Contributor

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.

@UFOXD
Copy link
Author

UFOXD commented Jul 12, 2019

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

@yekhlakov
Copy link

yekhlakov commented Jul 17, 2019

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
}

@UFOXD
Copy link
Author

UFOXD commented Jul 17, 2019

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

@ianlancetaylor
Copy link
Contributor

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.

@ianlancetaylor
Copy link
Contributor

There were no further comments.

@golang golang locked and limited conversation to collaborators Oct 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal Proposal-FinalCommentPeriod v2 An incompatible library change
Projects
None yet
Development

No branches or pull requests

6 participants