The point the GP was making was that the following Go snippet:

  func foo() {
    x := []int { 1 }
    //SNIP 
  }

Could translate to C either as:

  void foo() { 
    int* x = malloc(1 * sizeof(int));
    x[0] = 1;
    //...
  }

Or as

  void foo() { 
    int data[1] = {1};
    int *x = data;
    //...
  }

Depending on the content of //SNIP. However, some people think that the semantics can also match the semantics of the second version in C - when in fact the semantics of the Go code always match the first version, even when the actual implementation is the second version.

▲ 9rx 4 days ago | parent [-]

The semantics are clearly defined as being the same as the C code I posted earlier. Why would one try to complicate the situation by thinking that it would somehow magically change sometimes?

▲

simiones 4 days ago | parent [-]

Because people hear that Go supports value types and so is more efficient than Java because it can allocate on the stack*, and so they start thinking that they need to manage the stack.

* Of course, in reality, Java also does escape analysis to allocate on the stack, though it's less likely to happen because of the lack of value types.

	▲	9rx 4 days ago \| parent [-]
		I don't see the difficulty here. The slice is to be thought of as value type, as demonstrated in the C version. Just like in C, you can return it from a function without the heap because it is copied.