It's not possible to get the address (to point) of a constant value, which is why your initialization fails. If you define a variable and pass its address, your example will work.
type Config struct {
Uri *string
}
func init() {
v := "my:default"
var config = Config{ Uri: &v }
}
Getting a pointer to a string or any builtin type is super frustrating. Is there an easier way?
attempt1 := &"hello" // ERROR
attempt2 := &fmt.Sprintf("hello") // ERROR
const str string = "hello"
attempt3 = &str3 // ERROR
str2 := "hello"
attempt4 := &str5
func toP[T any](obj T) *T { return &obj }
attempt5 := toP("hello")
// Is there a builting version of toP? Currently you either have to define it
// in every package, or you have import a utility package and use it like this:
import "utils"
attempt6 := utils.ToP("hello")Context: https://github.com/aws/aws-sdk-go/issues/363
I came upon this while wondering why we have to use aws.String("xx") in aws go api calls.
The top answer starts with:
The aws.String is a helper so literal strings can be used when setting API field pointer values without needing to define a local variable first, because &"xxx" is not valid syntax. If the value is already defined as a local variable &xxxStr can also be used."
This part makes sense, you can't use a pointer to a literal string, it needs to be declared as a var (is there a name for this specifically?), as &"mystringhere" is not valid syntax, but rather a := "mystringhere", then &a.
However the next portion confuses me:
The AWS API operations include many optional fields which should not be included in the marshaled request if not set. In order to represent the ternary state for these fields pointers are used. This is done because it is not possible to distinguish between a never set value from a value set to the type's Zero value. The SDK uses pointers for all primitive and struct type fields. In many cases the type's Zero value of a field has meaning, and is different from unset, and a non zero value. All API fields in Input and Output structs are pointers, because even though a field is required today, it may not be required in the future. A breaking change would be required to allow not setting the once required field.
Can anyone explain this in semi non-go/programming terms? I'm trying to go through it step by step:
Calls to AWS APIs have optional fields that shouldn't be included in the request if they are not set
This means that vars that are not set, and thus have a nil or empty value, should not be sent in the request?
...Ternary state is represented by pointer...
This is just saying that the value passed to the API call is a pointer because there needs to be some flat value to pass to the API because go represents unset vars in different ways per type?
All API fields in Input and Output structs are pointers, because even though a field is required today, it may not be required in the future.
Everything passed to these API calls are pointers so that changes in the future don't break client code, and are handled on the AWS backend.
You pass a pointer to the "object" holding the string so that you can assign a different string to it.
Example: http://play.golang.org/p/Gsybc7Me-5
func ps(s *string) {
*s = "hoo"
}
func main() {
s := "boo"
ps(&s)
fmt.Println(s)
}
One reason, is you can use the pointer to differentiate between nil and zero
value:
package main
func f(s *string) {
switch {
case s == nil:
println("nil")
case *s == "":
println(`""`)
default:
println(*s)
}
}
func main() {
f(nil)
var s string
f(&s)
s = "north"
f(&s)
}
https://golang.org/ref/spec#The_zero_value
Taking the address of a literal (string, number, etc) is illegal because it has ambiguous semantics.
Are you taking the address of the actual constant? Which would allow the value to be modified (and could lead to a runtime error) or do you want to allocate a new object, copy the constant over and get the address to the new version?
This ambiguity does not exist in the case of test2 since you are dealing with an existing variable of which the semantics are clearly defined. The same would not work if the string was defined as const.
The language spec avoids this ambiguity by explicitly not allowing what you are asking for. The solution is test2. While it is slightly more verbose, it keeps the rules simple and clean.
Of course, every rule has its exceptions, and in Go this concerns composit literals: The following is legal and defined as such in the spec:
func f() interface{} {
return &struct {
A int
B int
}{1, 2}
}
For the question of the best solution for your situation of passing around "static" strings,
- Pass the string type instead of *string.
- Don't make assumptions about what is going on behind the scenes.
It's tempting to give the advice "don't worry about allocating strings" because that's actually true in the case you're describing where the same string is passed around, perhaps many times. It general though, it's really good to think about memory use. It's just really bad to guess, and even worse to guess based on experience with another language.
Here's a modified version of your program. Where do you guess that memory is allocated?
package main
import "fmt"
var konnichiwa = `こんにちは世界`
func test1() *string {
s := `Hello world`
return &s
}
func test2() string {
return `Hej världen`
}
func test3() string {
return konnichiwa
}
func main() {
fmt.Println(*test1())
fmt.Println(test2())
fmt.Println(test3())
}
Now ask the compiler:
> go tool 6g -S t.go
(I named the program t.go.) Search the output for calls to runtime.new. There's only one! I'll spoil it for you, it's in test1.
So without going off on too much of a tangent, the little look at the compiler output indicates that we avoid allocation by working with the string type rather than *string.