Proposal: Go 2: add builtin function printf, sprint(/f/ln)

[leaxoy]

There is already builtin functions for print, print and println, but for formatted data, we must import fmt for Printf function, so I propose to add printf function without import fmt each time.

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 format builtin function

func format(f string, arg ...Type) string

[martisch]

Please fill out the Go language change template and post the questions and answers here.
https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md

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.

[leaxoy]

I didn't realize that adding new functions would be so complicated. This is not a must, just for convenience and brevity.

[martisch]

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.
https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md

[ianlancetaylor]

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.

[jfesler]

@leaxoy, https://play.golang.org/p/arZt79IRtV7

You get what you want for apps you author, and the language doesn't change.

[davecheney]

@leaxoy here's an even shorter version

https://play.golang.org/p/4SMRujKS0Qe

[leaxoy]

Since is hard to implement, I find an alternative proposal. #34174. Without add new function, under the new proposal, we can easily do string interpolation, then pass it to println/print

[davecheney]

Closing in favor of #34174 per previous comment.