My intuition is that you win very little by adding more variants, and this will be very confusing to people trying to read code - particularly those new to Go. It's not that hard to write fmt.Fprintf("%x\n", foo) rather than fmt.Fprintlnf("%x", foo). And you get used to the \n suffix.

And you get used to the \n suffix.

This is what I thought would happen for me, but it hasn't. I still forget to add \n when using the f variations, especially when changing code from using Println to Printf to add formatting.

this will be very confusing to people trying to read code

Could you expand on why this will be very confusing?

I still forget to add \n when using the f variations, especially when changing code from using Println to Printf to add formatting.

Mistakes can happen. I imagine you're just as likely to forget to add ln than you are to forget to add \n, though.

Could you expand on why this will be very confusing?

More options to choose from, mainly. Especially since all these func names vary only by one or two characters. We already have quite a lot of variants, and they exist for a good reason. More variants when it's just a very minor convenience doesn't seem worth it to me.

I don't like this idea. The Println variant differs from Print and Printf in two ways, one obvious (the newline) and one subtle: its treatment of arguments that are strings with leading or trailing whitespace. For example:

https://play.golang.org/p/aLlMHWQbCkC

fmt.Sprint(" a ", " b ") == " a  b " // two spaces
fmt.Sprintln(" a ", " b ") == " a   b \n" // three spaces

What does the lnf variant do? I cannot guess, and nor should I have to.

It might make it clearer if the function was named fln, or Printfln, so it's clearer that this is a Printf function with a new line appended.

@adonovan Would that make the fln variant clearer?

What does the lnf variant do?

The f variant does not add spaces because it receives only a single string for formatting, so the fln variant should not either.

@adonovan Would that make the fln variant clearer?

No. The problem is that behavior of lnf (or fln) is not the composition f and ln. It is yet another thing readers must commit to memory.

#46190 (comment) is the major reason not to do this. Println is not Print+\n. It changes other things that make no sense to change in Printf.

@rsc @adonovan If we think of Printf as Print(Sprintf(...)) and Printlnf as Println(Sprintf(...)) then there's no confusion. Print(ln)'s weird behaviour with multiple arguments doesn't apply, and the only relevant difference is the fact that Println appends a newline. I don't think that alone is sufficient reason to reject this proposal.

I'm somewhat in favor of this proposal. Like @leighmcculloch, I often forget \n in my format strings, particularly when converting a Println call to a Printf call. Having Printlnf available would probably help alleviate that. However, i'm not sure if the minor benefits are worth the new API.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

i'm not sure if the minor benefits are worth the new API

The main problem this solves is addressing the mistake some of are repeatedly making with missing \n in print calls. To that end, adding a lnf variation for every existing fmt function would probably be unnecessary. I think the proposal could be limited to adding Printlnf and Fprintlnf. Originally I was thinking other functions, such as Sprintlnf, should be added for consistency, but that is a much larger API change. If we limit the proposal to only adding Printlnf and Fprintlnf, the scope of the new API introduced is much smaller and focused on the problem.

I too sometimes forget to put \n in my format strings, but those mistakes are always balanced out by having too many newlines (using Println when I should have used Print for example). I always end up gravitating back to Printf for everything, and if I make a couple mistakes, oh well.

There are clear reasons in this thread why these proposed functions would be confusing, and the design decisions around Print and Println make it pretty clear that if precise formatting matters to you, you should just be using Printf.

I don't think the inevitable confusion could ever be worth it for a problem as trivial as forgetting a newline.

@rsc @adonovan If we think of Printf as Print(Sprintf(...)) and Printlnf as Println(Sprintf(...)) then there's no confusion.

But that's not what Println means.

@rsc @adonovan If we think of Printf as Print(Sprintf(...)) and Printlnf as Println(Sprintf(...)) then there's no confusion.

But that's not what Println means.

Did you mean that's not what Printf means? Because @magical only provides definitions for Printf and Printlnf, not Println.

Comparing the definitions of Printf and Sprintf, it does seem like Sprintf is a subset of Printf's behavior.

Printf formats according to a format specifier and writes to standard output.

https://golang.org/pkg/fmt/#Printf

Sprintf formats according to a format specifier and returns the resulting string.

https://golang.org/pkg/fmt/#Sprintf

Println(Sprintf(...)) exhibits none of the special behavior of Println, so Printlnf would therefore be confusing to anyone who knows how Println works.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

My intuition is that you win very little by adding more variants, and this will be very confusing to people trying to read code - particularly those new to Go. It's not that hard to write fmt.Fprintf("%x\n", foo) rather than fmt.Fprintlnf("%x", foo). And you get used to the \n suffix.

It is actually hard to write when you‘re on a German keyboard. The backslash is a pain and it would be great not having to use it all the time for simple log statements.

This feels like one of those real problems that can be trivially solved within each project, versus making it an explicit feature of the language and needing to support the API in perpetuity (i.e., until Go 2). If you run into this problem often, you could copy this helper function into all the packages you use that need it. It seems like it would be unlikely to change, and so it feels like a great candidate for "A little copying is better than a little dependency":

func printf(format string, a ...interface{}) (n int, err error) {
    return fmt.Printf(format+"\n", a...)
}

Println(Sprintf(...)) exhibits none of the special behavior of Println, so Printlnf would therefore be confusing to anyone who knows how Println works.

This argument doesn't make sense to me. We already have Printf and nobody is confused that it doesn't work like Print. Do you expect Printf("%d%d", 1, 2) to insert spaces between the two numbers? No, and you wouldn't expect that from Printlnf either.

No change in consensus, so declined.
— rsc for the proposal review group