proposal: fmt: add a %*T verb

[zigo101]

Sometimes, I want to print the type of a value (not for debug purpose).
If the size of the value is large, then the fmt.Printf call is inefficient. For example:

package main

import "fmt"

var a [1000]int

func main() {
	fmt.Printf("My type is %T \n", a) // a will be copied.
}

So I propose to add a %*T verb, which represents the element or base type of the corresponding argument, so that the address of the large value can be passed as argument instead.

package main

import "fmt"

var a [1000]int

func main() {
	fmt.Printf("My type is %*T \n", &a) // a will not be copied.
}

BTW, is %& an undocumented verb?

[edit] %*v and %*#v are also wanted.

[davecheney]

For almost any type, the cost of the syscall and terminal io will be much greater than boxing a copy of a inside an interface value. I don’t thing this is necessary

…

On 7 Jul 2018, at 22:28, Go101 ***@***.***> wrote: Sometimes, I want to print the type of a value (not for debug purpose). If the size of the value is large, then the fmt.Printf call is inefficient. For example: package main import "fmt" var a [100]int func main() { fmt.Printf("My type is %T \n", a) // a will be copied. } So I proposal add a %*T verb, so that I can pass the address of the large value as argument instead. package main import "fmt" var a [100]int func main() { fmt.Printf("My type is %*T \n", &a) // a will be copied. } BTW, is %& an undocumented verb? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[zigo101]

How about the type of a is [10000000]int?

[davecheney]

Your example is contrived. This is an unnecessary change.

…

On 7 Jul 2018, at 22:33, Go101 ***@***.***> wrote: How about the type of a is [10000000]int. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[zigo101]

So a copy is inevitable?

[davecheney]

In the scenario you have described, yes. I argue your scenario is contrived and this is a really edge case optimisation.

…

On 7 Jul 2018, at 22:50, Go101 ***@***.***> wrote: So a copy is inevitable? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[zigo101]

Yes, it is a little edge.

In fact, sometimes I also want %*v and %*#v, which would be used more frequently than the %*T.

[davecheney]

I think you are over focused on the copy. Copy’s happen all the time, every assignment in go is a copy, every function call. Every return, is a copy. Copying is something CPU’s are *really* good at, esp3cially if the thing being copied is large. Copying isn’t usually a problem unless you’re doing it in the centre of a hot loop, and as I said before, printing is far more expensive.

…

On 7 Jul 2018, at 23:16, Go101 ***@***.***> wrote: Yes, it is a little edge. In fact, sometimes I also want %*v and %*#v, which would be used more frequently than the%*T`. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[zigo101]

For most Go values, copying is not a problem. But for copying large sized arrays and structs, it is possible a problem.

[mvdan]

If you really had this in a hot path, you could use the reflect package directly to get the type of a variable. I'm sure that gives you more options than fmt.Sprintf("%T", ...).

[zigo101]

Reflection is a workable. It is just that the reflect package is the last package I'm willing to use. :)
I would use fmt.Sprintf("%T", &a)[1:] instead, even if it is some ugly.

[mvdan]

You seem to expect fmt to be easy to use, but also fast for uncommon edge cases. I don't think that's a proposal that's going to be accepted. Adding %*T adds complexity to the API, for example.

[zigo101]

I admit it is a micro-optimization. It is just a little more beautiful and efficient than the current alternative ways.
Just another detail to show the design of Go is to satisfy 99% use cases, but not good for the other 1% use cases.

[rsc]

Today for debugging you could print the pointer type directly and mentally remove the star, or else you could use reflect.TypeOf(&a).Elem().String(). This is not nearly prevalent enough to warrant a special case in the %T fmt verb.

It seems to me unfair to claim that "Go is to satisfy 99% use cases, but not good for the other 1% use cases." For the other 1% use cases Go is still good but you might have to write some code instead of assuming everything you need is built-in. That's what keeps Go small, because everyone's 1% is different and adds up to about 1,000,000%.