1. Can you give an existing code example where this would be helpful and why it does improve the code in the example?

2. if each & gives a new memory address does that mean that each time an address of a constant is taken at runtime it needs to copy the constant into new memory and return a pointer? That would seem a lot of hidden cost behind & for constants being different then e.g. for variables. Which would raise the question for me what the advantage is over initializing a variable with the constant and then taking the address of the variable.

3. Would the type of a pointer to a string constant be the same as the type of a pointer to a string?

This is #19966, which was closed as a special case of the more general #9097 (see e.g. #9097 (comment)).

Can you give an existing code example where this would be helpful and why it does improve the code in the example?

My bad, I should have included real-world examples.

The main advantage is brevity. Especially when working with constructs that have nullables (ie JSON) structures need to have *string values rather than simply string.

*string is also used frequently in structs made for passing lots of parameters to a function. This makes it possible to tell the difference between explicitly providing an empty string and not including the argument.

Initializing these structs that use *string quickly becomes painful. For instance, with AWS:

// standard Go way without `aws.String` convenience function
var bucket = "MyBucket"
var key = "SomeFile.pdf"
downloader.DownloadWithContext(ctx, buffer, &s3.GetObjectInput{
	Bucket: &bucket,
	Key: &key
})

Now imagine calling that function but using all of the possible parameters

AWS realized that this was a problem, so they provided a "solution":

func String(str string) *string {
	return &str
}

So then our function call would look like:

downloader.DownloadWithContext(ctx, buffer, &s3.GetObjectInput{
	Bucket: aws.String("MyBucket"),
	Key: aws.String("key")
})

The repetition of aws.String is still quite painful. Again, think about needing to use that for every single AWS call.

if each & gives a new memory address does that mean that each time an address of a constant is taken at runtime it needs to copy the constant into new memory and return a pointer? That would seem a lot of hidden cost behind & for constants being different then e.g. for variables.

That is fair I guess. Having it shown over two lines is good to show that there is extra cost. I'd personally call that a micro-optimization though. After all &"hello" would be equivalent to hello := "hello"; &hello. I wouldn't exactly call that expensive. I really would think of it as more syntactic sugar. It would only be more expensive if you create lots of pointers to the same value.

Which would raise the question for me what the advantage is over initializing a variable with the constant and then taking the address of the variable.

Again, my AWS example is what I'm trying to avoid.

This is #19966, which was closed as a special case of the more general #9097 (see e.g. #9097 (comment)).

My bad, you are correct. Closing this.