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: fmt: add a %*T verb #26262

Closed
go101 opened this issue Jul 7, 2018 · 13 comments

Comments

@go101
Copy link

commented Jul 7, 2018

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.

@gopherbot gopherbot added this to the Proposal milestone Jul 7, 2018
@gopherbot gopherbot added the Proposal label Jul 7, 2018
@davecheney

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2018

@go101

This comment has been minimized.

Copy link
Author

commented Jul 7, 2018

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

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2018

@go101

This comment has been minimized.

Copy link
Author

commented Jul 7, 2018

So a copy is inevitable?

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2018

@go101

This comment has been minimized.

Copy link
Author

commented Jul 7, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2018

@go101

This comment has been minimized.

Copy link
Author

commented Jul 7, 2018

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

@mvdan

This comment has been minimized.

Copy link
Member

commented Jul 7, 2018

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", ...).

@go101

This comment has been minimized.

Copy link
Author

commented Jul 7, 2018

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

This comment has been minimized.

Copy link
Member

commented Jul 7, 2018

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.

@go101

This comment has been minimized.

Copy link
Author

commented Jul 7, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2018

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%.

@rsc rsc closed this Jul 9, 2018
@golang golang locked and limited conversation to collaborators Jul 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.