Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Proposal: Go 2: add builtin function printf, sprint(/f/ln) #40856
There is already builtin functions for print,
func printf(f string, args ...Type)
For string build and formatted, we can also add string print functions.
func sprint(args ...Type) string func sprintf(f string, ...Type) string func sprintln(args ...Type) string
or the single
func format(f string, arg ...Type) string
Please fill out the Go language change template and post the questions and answers here.
Can you explain why is this needed? Is it to save the one line to import "fmt" ?
AFAIK the existing print is added not for convience of general Go programs but for easier bootstrapping of compiler/runtime without a standard library. To be easy to implement it is not as powerful as the fmt package.
Implementing the proposal will mean to pull in all the complexity of reflect, unicode and other packages into the Go runtime and every Go program. As print is part of the language spec it will also pull in all the specification of the fmt package into the language spec. I would note that fmt is not without historic sharp edges that should be corrected if they are further restricted to never change as part of the language spec and also need to be honored by other Go compilers.
Its alot of complexity and churn for the Go ecosystem (other compilers) and specification of the Go languages all for not having to write 'import "fmt"' (and no new features that allow for more concise or performant writing of Go code) seems not to be a good tradeoff. Using an IDE also automates the adding the import line for many Go developers already.
There are pros and cons to every change which need to be carefully evaluated.
To make it a full proposal please take the time to fill in the template so the thought and motivation behind the proposal is understood for discussion and evaluation.
This is a fairly big change to the language. The fmt package is quite complicated. All of that complexity would become part of the language proper, rather than being in a separate package that can be updated and fixed over time.
We would need a very good reason for making a change like this. Convenience and brevity are not good enough reasons.