Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

If f returns a pointer to a struct, I think it would be fairly unfortunate that &f() and &f().x mean significantly different things. The first would allocate new heap memory, copy the result of f() into that memory, and then take its address. The second would simply take the address of the field x in the struct pointer returned by f, without allocating any new memory. This means that two operations that look very similar would behave significantly differently.

This is related to #45624.

simply take the address of the field x in the struct pointer returned by f, without allocating any new memory

Interesting. If it is possible to take the address of a field of the value returned by f, what's the distinction between getting the address of the value vs a field of the value?

This means that two operations that look very similar would behave significantly differently.

Would they behave differently to the developer, or only to the runtime? My understanding is the behavior difference would be in the runtime, which seems less of an issue. What problems does this behavior difference create?

In one case you have the only pointer to the value and in the other case you have a pointer that other code may also have. That's a pretty big difference when trying to understand the behavior of your code with multiple goroutines.

For example, you know that &f() gives you a unique pointer. Suppose you want a unique pointer. Then you write &f().x, but now you don't have a unique pointer. Or maybe you write &(&f()).x, and now you do have a unique pointer. To be clear, none of this is a fatal problem. But in general it's best if code that looks similar behaves the same way, and it's a problem if code that looks similar behaves significantly differently.

This is related to #45624.

To elaborate, if #45624 is accepted, instead of &time.Now(), you would write something like &time.Time(time.Now()), new(time.Time, time.Now()), or new(time.Now()), depending on what spelling(s) the accepted proposal allows.

Pointer expression to any value (including return of function) already exist. They are just ugly.

Example (see on the Go playground):

	nowPtr := &(&struct{ time.Time }{time.Now()}).Time

	fmt.Printf("%T %[1]v\n", nowPtr)
	// Output: *time.Time 2009-11-10 23:00:00 +0000 UTC m=+0.000000001

@dolmen FWIW, a more concise (but still ugly) spelling would be &[]time.Time{time.Now()}[0].

Would this proposal affect slices as well? (I can file a separate proposal if this is best discussed on its own task.)

Right now, one must do:

h := sha256.Sum256(b)
x := SomeStruct{
    Algo: AlgoSHA256,
    Hash: h[:],
}

It'd be much more convenient to be able to write:

x := SomeStruct{
    Algo: AlgoSHA256,
    Hash: sha256.Sum256(b)[:],
}

In Go 1.16, the above results in invalid operation sha256.Sum256(b)[:] (slice of unaddressable value).

Behind the scenes, I would expect the compiler to automatically perform the copy of the return value to back the desired slice.

Looking at the proposed new syntax in #45624, I'd also be open to something like:

x := SomeStruct{
    Algo: AlgoSHA256,
    Hash: new([]byte, sha256.Sum256(b)),
}

...although that seems much less clear to me.

Would this proposal affect slices as well?

I would recommend that it does not. The fact that & can be used for composite literals to implicitly allocate variables is rather special, and I think we'd do best to keep it minimal to avoid confusion. For example, Go allows (&[7]int{})[:], but not [7]int{}[:]. Similarly, (&T{}).M() is allowed for pointer-received methods, but not T{}.M().

If the variant form new(value) (as opposed to new(type, value)) discussed in #45624 is accepted, you could write new(sha256.Sum256(b))[:]. I'd prefer to encourage that than to allow new([]byte, sha256.Sum256(b)) (i.e., where the specified type can differ from the value expression's type).

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

@seankhliao Thanks for the link. Done!

@gopherbot please remove label WaitingForInfo

With generics, we could use

func PtrTo[T any](v T) *T { return &v }

    s := S{
        Time: PtrTo(time.Now())
    }

to take the address of any value.

Based on the discussion above this is a likely decline. Leaving open for four weeks for final comments.

No further comments.