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

> You can only take a reference to an lvalue, which is (essentially) an expression that is legal to use in the form `my_lvalue = ….

I mean it could implicitly allocate, that's what Rust does for instance.

Your second and third attempts would not compile though, the first would by returning a `&'static T`.

"implicitly allocate" is slightly misleading, imho. It's promoted to a static. There's no malloc involved.

> "implicitly allocate" is slightly misleading

Maybe. I just meant that storage is created implicitly (static or stackframe depending on the case), then a reference is created to that.,

Totally, I don't think you're wrong, just like, people read "allocate" in different ways. I wish words were clearer, heh.

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 [].