Minutes ago I was wondering about https://play.golang.org/p/9C0puRUstrP (via https://github.com/golang/go/issues/23440).

Thank you for explaining what's going on there! :)

And btw, compiling the above example with -gcflags="-m" (which I learned about earlier today) proves you right.

> it's an allocation

Most people probably think "heap allocation" when you say this. Go doesn't do dynamic allocations within a stack frame (alloca in C), so when you say "it's an allocation", what does that mean? It could be a stack allocation that occurred at compile time as a reservation in the size of the stack frame for that function. It could be a heap allocation. Only the compiler knows!

The Go compiler is the ultimate authority on what becomes a heap allocation. It tries to make everything into a stack allocation when possible, and stack allocations are "free".

Beyond that, a sufficiently smart compiler can reuse stack "allocations" within a single function as certain values become "dead" (never used again). So there isn't even guaranteed to be a 1:1 correspondence between "stack allocations" and variables that you declared inside the function.

So, I completely disagree with your statement about Go being "relatively explicit about allocations." It's one of the least explicit compiled languages in that regard.

Go makes a distinction between declaration and assignment, which is the syntax you're talking about. It really has nothing to do with allocations.

I don't see how:

  temp := someFunc()
  p := &temp

is any less explicit than

  p := &someFunc()

It seems that the `&` is still required to put something onto the heap.

    x := make(map[int]int)
    x[0] = 5
    
    y := &x[0]
    *y = 10
    
    print(x[0]) // 5 or 10?
    
    x[0] = 6
    
    print(*y) // 6 or 10?
    
    // force the map to grow and reallocate the buckets
    for j := 1; j < 100; j++ {
        x[j] = j
    }
    *y = 11
    
    print(x[0]) // 5, 6, 10, or 11?

I think the way to say it is that Go requires you to declare every allocation, but allows over-declaration in the case of copying.

> := [...] an error to use it when it doesn't allocate.

> := [...] not allocating if you have a variable on the left that is already allocated,

This appears to be a contradiction.

I suppose you mean something like "error to use it when there's no possible context where that line of code would allocate"; what's an example of that?

I’m not sure I understood this correctly. Does the following allocate (on the heap)?

    foo := MyStruct{}

  foo := MyStruct{} // Could live on the stack
  _ := &foo // Oh, now foo must live on the heap.

No, but in C you can't apply `&` to any stack value and "automagically" pop it onto the heap. Or from another point of view everything in Go is logically on the heap, the compiler just optimizes values that don't have their address taken to live on the stack.

In C:

  int *f() {
    int x = 0;
    return &x;
  }

It works, but it is wrong. The C type system isn't smart enough to realize the lifetime of x in this case. It is not allowed for a function return because C does have the concept of a temporary value so it is disallowed because it is basically always incorrect to do so.

Note that C++ does somewhat allow this with lifetime extension. It is somewhat like what I expected Go to do, except because lifetime extension only extends to the enclosing block it is more of a footgun. With a dynamic tracing garbage collector like Go it not a footgun.

Nope. You can only take a reference to an lvalue, which is (essentially) an expression that is legal to use in the form `my_lvalue = .... Otherwise, there's nothing to take the reference of.

    int* ref1() {   return &1; }
    
    -> error: lvalue required as unary '&' operand
   
    // 

    #include <stdlib.h>
    int alloc()  {
      return *(int*)malloc(sizeof(int));
    }
    int* ref() {  return &alloc();  }

    ->  error: lvalue required as unary '&' operand

You can still be unsafe though, by making a reference to a stack-allocated object and letting it go out of scope :

    int* make_unsafe_ref() {  int a; return &a;  }
    ->  warning: function returns address of local variable

Yes, if f() returns the type T then you can write

    &(T[]){ f() }

The type in brackets needs to be an array so that if f() returns a struct then the initializer list has the right shape. If T is a simple type then you can drop the [].

There's a double connotation being played with there, a web developer vs the web developer

He did develop the web.

When you know JavaScript enough to be able to say that you don't know JavaScript.

When you have two questions about a specific feature that every change proposal must answer, it's a sign that something needs improvement.

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));

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.

Ok I think I'm not understanding this correctly then. Why does this return an error?

    package main

    import (
        "fmt"
    )
    
    const tst = 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    
    func main() {
        fmt.Println("%v", tst)
    }

Error: ./prog.go:16:17: constant 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 overflows int

See: https://play.golang.org/p/47l5qAsXD5r

An other big use-case for pointers to pointers in C is pointer-type out parameters. Most of that use-case is handled by MRV, but I'm pretty sure there's the odd situation where a double pointer is either necessary or convenient (I remember seeing the odd one in Rust once in a while).

Pointer-pointers are nice to implement linked data structures in C; they make a lot of logic surrounding re-seating the head pointer far simpler and with fewer edge cases.

It does have a type. You just wrote it down!