[whateveracct]

I have so many BS helpers in my project to do this

    util.StrPtr("hello")
    util.BoolPtr(false)
    util.Int64Ptr(7)
    // etc

This is just a gap in Go's design, so I'm glad this proposal exists :)

[gher-shyu3i]

Generics would solve the issue.

[majewsky]

Not entirely. Someone in the comments of the issue suggests to implement this with generics as:

  func PointerOf[T any](t T) *T {
    return &t
  }

But that has a nasty gotcha:

  func Process(x *int32) {
    if (x != nil) {
      fmt.Println(*x + 5);
    }
  }

  func main() {
    Process(nil);          //ok
    x := i32(5)
    Process(&x);           //ok
    Process(PointerOf(5)); //BOOM: cannot use PointerOf(5) (value of 
                           //type *int) as *int32 value in argument to Process
  }

Go's type coercion is quite primitive. It strictly works inside-out (propagating types strictly upwards in the AST), with the only exception that a numeric literal can be coerced into a specific numeric type by considering the immediate parent in the AST. So when you have `func f(x int32)` and you call it as `f(5)`, the literal 5 gets coerced into int32 to match the context it appears in. (The same strategy is also applied to determine the type of a nil literal.)

However, in `Process(PointerOf(5))`, the immediate surrounding of the literal 5 (the PointerOf call) does not coerce the literal into a specific type, so it takes on its default type, int.

The proposal (or, to be exact, both proposals) avoids this gotcha by requiring a type to be stated explicitly.

    Process(new(i32, 5));
    Process(&i32(5));

[bbatha]

You can just write PointerOf(int32(5)) or PointerOf[int32](5). Or go could improve its type inference.

[Groxx]

Well. It would reduce it to 1 (PtrTo) instead of [however many]. And unless they also add a new top-level func like that, it's still a `package.PtrTo` rather than `&`. And `&`'s special abilities on only composite literals remains.