3 ms·

Generics would solve the issue.

• Groxx 6y ago
  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.
• majewsky 6y ago
  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 6y ago
    You can just write PointerOf(int32(5)) or PointerOf[int32](5). Or go could improve its type inference.